Технологии программирования на базе Microsoft Solutions Framework

Цели и задачи курса и практикума

Разбить на страницы
Показывать лекцию целиком

1. Цели и задачи курса и его место в учебном процессе

1.1. Цель преподавания курса

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

Цель данного курса состоит в изучении основных путей организации и проведения успешных проектов в области разработки программного обеспечения на базе принципов Microsoft Solutions Framework (MSF). Важная роль отводится практической составляющей курса.

1.2. Задачи изучения курса

В рамках изучения курса предполагается решение следующих задач:

  • рассмотрение технологических основ процесса разработки программного обеспечения;
  • изучение основ унифицированного языка UML для визуального моделирования элементов предметной области в рамках проектирования программной системы и ее основных компонент;
  • получение практического опыта работы в команде из 5-7 человек с применением методологии MSF;
  • приобретение и развитие навыков анализа, проектирования, документирования и разработки программных комплексов средней сложности.
  • По окончании изучения курса студенты будут уметь использовать методологию Microsoft Solutions Framework for Agile Software Development, включая:

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

    Курс опирается на материалы следующих курсов: CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", CS105 "Дискретная математика" . Предполагается, что данный курс читается параллельно с курсом CS103 "Алгоритмы и структуры данных" с запаздыванием в 1 семестр (рис 1).

    (рис 1) Предполагаемая последовательность изучения курсов. Закрашенные части читаются одновременно

    2. Характеристика курса

    Данный курс читается в 4-ом семестре и опирается на прочитанные ранее общие курсы CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", в рамках которых студенты знакомятся с фундаментальными понятиями, принципами и методами программирования, изучают основные алгоритмы, простейшие структуры данных, языки программирования Object Pascal и C/C++. В 3-ем семестре студенты изучают первую часть курса CS103 "Алгоритмы и структуры данных", выполняют лабораторные работы согласно учебному плану. Таким образом, полученных к 4-му семестру знаний и навыков достаточно для того, чтобы приступить к ознакомлению с технологиями коллективной разработки программ.

    Конечно, уровень студента 2 курса все еще не позволяет овладеть этой темой полностью, поэтому учебный план предполагает изучение нескольких последовательно расположенных курсов, первым из которых, вводным, является данный курс - "Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)".

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

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

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

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

    Рассмотрим кратко основные разделы курса и их содержание.

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

    Основная часть курса состоит из трех разделов.

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

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

    Во втором разделе курса (лекции 3, практики 1, 2, 3) идет речь о принципах объектно-ориентированного анализа и проектирования программного обеспечения при помощи визуальных средств языка UML. Дается обзор принципов объектного подхода, рассматриваются важные аспекты повторного использования, рассматриваются элементы языка UML. Демонстрируется применение UML для визуализации проектирования лекционных примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных".

    В третьем разделе курса (лекции 4, 5, 6, 7, практики 4, 5, 6, 7, 8) изучается методология разработки программного обеспечения Microsoft Solutions Framework 4.0. Рассматривается история MSF, основные принципы MSF, модель проектной группы, роли и фазы MSF. Через все фазы проводится лекционный пример - разработка системы бронирования билетов для аэропорта.

    3. Содержание курса

    Введение

    Важность предмета.

    Программа и программное обеспечение, основные отличия. О рынке программного обеспечения.

    Сложность управления процессом разработки программного обеспечения.

    Технологии программирования как способ борьбы со сложностью.

    Обзор технологий программирования (структурное, модульное, объектно-ориентированное, компонентное программирование).

    Цели и задачи курса. Структура учебного плана. Основная и дополнительная литература, Интернет-источники.

    1. Элементы программной инженерии.

    1.1. Программная инженерия, основные понятия.

    Инженерия и инженеры.

    Программная инженерия как инженерная дисциплина.

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

    Программные инженеры и их деятельность.

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

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

    1.2. Процесс создания программного обеспечения

    Понятие процесса создания ПО. Основные стадии процесса.

    Модели процесса создания ПО. Каскадная и эволюционная модели.

    Итерационные модели процесса создания ПО. Модель пошаговой разработки, спиральная модель.

    2. Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (UML).

    2.1. Анализ и проектирование. Некоторые частные вопросы

    2.1.1. Обзор принципов объектного подхода.

    Алгоритмическая и объектная декомпозиции. Классы и объекты.

    Объектно-ориентированный анализ.

    Объектно-ориентированное проектирование.

    Объектно-ориентированное программирование.

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

    Пример: ООП и структуры данных. Проектирование структуры данных стек.

    2.1.2. Повторное использование.

    Идея повторного использования. Важность повторного использования.

    Достоинства повторного использования. Виды повторного использования.

    2.2. Визуальное моделирование. История языка UML.

    Идея визуального моделирования.

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

    История возникновения и развития языка UML.

    2.3. Структура языка UML.

    Модели UML.

    Диаграммы и понятия UML.

    2.4. Учебный пример: Задача о разработке программного комплекса бронирования билетов для авиакомпании "SRS - Seat Reservation System". Постановка задачи.

    2.5. Визуальное описание модели функционирования системы средствами UML.

    Понятия Актера и Варианта использования.

    Ассоциация между Актером и Вариантом использования.

    Диаграмма вариантов использования.

    Диаграмма действия.

    Пример: Использование средств UML для визуального моделирования поведения программной системы "SRS".

    2.6. Классы, объекты, поля, методы, подсистемы, компоненты, пакеты и их отображение средствами UML.

    Пример: Использование средств UML для визуального проектирования программной системы "SRS".

    2.7. Проектирование системы. Диаграммы классов и их описание средствами UML.

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

    Пример: Использование средств UML для визуального проектирования программной системы "SRS".

    3. Методология создания программных решений Microsoft Solutions Framework.

    3.1. Введение в методологию MSF и историческая справка.

    Что такое MSF. Основные концепции методологии: модель процессов, управление проектом, модель проектной группы, управление рисками. Позиционирование MSF в сравнении с другими методологиями разработки программного обеспечения. Инструментальная поддержка методологии до версии 3.0 включительно. Источники информации.

    3.2. Нововведения версии MSF 4.0.

    Разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. Причины разделения методологии MSF на "облегченный" и "тяжелый" варианты, основные отличия направлений. Почему в основу курса положено направление MSF for Agile Software Development? Характеристика основных положений MSF for Agile Software Development. Инструментальная поддержка MSF 4.0 в среде разработки Microsoft Visual Studio 2005. Источники информации.

    3.3. Формирование команды. Модель проектной группы MSF for Agile Software Development.

    Основные принципы построения команды.

    "Проектная группа - команда равных".

    Каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны.

    "Масштабируемость" модели проектной группы в зависимости от числа участников.

    Ролевые группы и роли, зоны ответственности ролевых групп, их задачи и взаимодействие с заинтересованными лицами.

    MSF for Agile Software Development выделяет 7 ролевых групп: управление программой, архитектура продукта, разработка, тестирование, управление выпуском, удовлетворение потребителя, управление продуктом, - и 6 ролей: менеджер проекта, архитектор, разработчик, тестер, релиз-менеджер, бизнес-аналитик. Для каждой группы и роли, помимо зоны ответственности, в которой роль имеет решающий голос, определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять/отстаивать при принятии решений.

    Рекомендации по возможному объединению ролей.

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта.

    3.4. Управление рисками в MSF for Agile Software Development.

    Основные сведения о рисках.

    Планирование управления рисками.

    Процесс управления рисками: выявление, анализ и приоритезация, планирование, мониторинг, корректирование, извлечение уроков.

    Управление рисками как составная часть жизненного цикла проекта.

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выделение рисков.

    3.5. Модель процессов MSF for Agile Software Development.

    Принципы модели процессов.

    Взаимодействуйте с "заказчиками".

    Поощряйте свободный обмен информацией в проекте.

    Создавайте "единое видение проекта".

    Следите за качеством продукта.

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

    Ставьте "вехи".

    Будьте готовы к внедрению сегодня.

    Схема процесса разработки.

    Основные структурные единицы схемы: циклы, фазы и вехи.

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

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

    3.6. Старт проекта. Фаза выработки концепции.

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

    Задачи ролевых групп на фазе выработки концепции.

    Главная веха фазы: "Концепция утверждена".

    Рекомендуемые промежуточные вехи: "Ядро проектной группы сформировано", "Черновой вариант концепции проекта составлен".

    Результаты фазы: "Общее описание и рамки проекта", "Документ оценки рисков", "Описание структуры проекта".

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выработка концепции.

    3.7. Планирование проекта. Фаза планирования.

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

    Категории проектных требований. Уровни процесса проектирования.

    Задачи ролевых групп на фазе планирования.

    Главная веха фазы: "Планы проекта утверждены".

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

    Результаты фазы: "Функциональная спецификация", "План управления рисками", "Сводный план и сводный календарный график проекта".

    3.8. Разработка решения. Фаза разработки.

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

    Задачи ролевых групп на фазе разработки.

    Главная веха фазы: "Разработка завершена ".

    Рекомендуемые промежуточные вехи: "Концепция подтверждена", "Билд номер N завершен", "Билд номер N+1 завершен",…

    Результаты фазы: "Исходный и исполняемый код приложений", "Скрипты установки и конфигурирования", "Окончательная функциональная спецификация", "Материалы поддержки решения", "Спецификации и сценарии тестов".

    3.9. Стабилизация решения. Фаза стабилизации.

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

    Задачи ролевых групп на фазе стабилизации.

    Главная веха фазы: "Готовность решения утверждена".

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

    Результаты фазы: "Окончательный продукт", "Документация выпуска", "Материалы поддержки решения", "Результаты и инструментарий тестирования", "Исходный и исполнимый код приложений", "Проектная документация", "Анализ пройденной фазы".

    3.10. Внедрение решения. Фаза внедрения.

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

    Задачи ролевых групп на фазе внедрения.

    Главная веха фазы: "Внедрение завершено".

    Рекомендуемые промежуточные вехи: "Ключевые компоненты развернуты", "Внедрение на местах завершено", "Внедренное решение стабилизировано".

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

    4. Затрагиваемые разделы рекомендаций Computing Curricula 2001 (Software Engineering 2004)

    Данный курс является вводным курсом в рамках направления "Программная инженерия" и затрагивает следующие элементы курса SE201:

    CMP.ct - Технологии разработки

    MAA.md - Моделирование

    MAA.tm - Типы моделей

    MAA.rfd - Требования

    MAA.rsd - Спецификация и документирование требований

    MAA.rv - Проверка требований

    DES - Проектирование

    PRO.imp - Процесс разработки

    MGT - Управление процессом разработки

    5. Учебно-методические материалы по курсу

    5.1. Литература

  • И. Соммервиль. Инженерия программного обеспечения, 6 изд. - И.д. "Вильямс", 2002.
  • Г. Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание. - Бином, 1998.
  • N. Wirth. Program Development by Stepwise Refinement // Communications of the ACM vol.26(1).- 1971, 1983.
  • O. Dahl, E. Dijkstra, C.A.R. Hoare. Structured Programming.-London, England: Academic Press, 1972.
  • Р. Лингер, Х. Миллс, Б. Уитт. Теория и практика структурного программирования. - М.: Мир, 1982.
  • Э. Салливан. Время - деньги. - М.:Microsoft Press, Русская редакция, 2002.
  • Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя. - ДМК-Пресс, Питер, 2004.
  • G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004.
  • Модель процессов MSF. Белая книга, 2003, перевод eLine Software.
  • Дисциплина управления рисками MSF. Белая книга, 2003, перевод eLine Software.
  • Модель проектной группы MSF. Белая книга, 2003, перевод eLine Software.
  • 1846A: Microsoft Solutions Framework Essentials. Microsoft Official Course, 2002
  • 2710B: Analyzing Requirements and Defining Microsoft .NET Solutions Architecture. Microsoft Official Course, 2003
  • MSF Process Model. White paper, 2002 Microsoft Corporation.
  • MSF Risk Management Discipline. White paper, 2002 Microsoft Corporation.
  • MSF Team Model. White paper, 2002 Microsoft Corporation.
  • 5.2. Информационные ресурсы сети Интернет

  • Ian Sommerville. Software Engineering. 6th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6]
  • Ian Sommerville. Software Engineering. 7th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7]
  • http://www.uml.org
  • http://www.wikipedia.org
  • http://www.microsoft.com/msf
  • С. Якимчук. MSF - философия создания IT-решений или голые амбиции лидера, 2004: [http://www.citforum.ru/SE/project/msf/].
  • Алистер Кокбёрн. Каждому проекту своя методология:[http://software-testing.ru/lib/cockburn/methodology-per-project.htm](перевод статьи Alistair Cockburn. Methodology per project: [http://alistair.cockburn.us/index.php/Methodology_per_project]).
  • А. Терехов, А. Ложечкин. Microsoft Solutions Framework 4.0 - опыт Microsoft по организации командной разработки. Презентация с Microsoft Платформа 2006
  • MSF for Agile Software Development Process Guidance: [http://go.microsoft.com/fwlink/?linkid=63524]
  • Цели и задачи лабораторного практикума

    Цель данного лабораторного практикума состоит в практическом знакомстве с процессом командной разработки программного обеспечения на примере Microsoft Solutions Framework (MSF).

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

  • начальное освоение унифицированного языка моделирования UML;
  • получение практического опыта работы в команде из 5-7 человек;
  • освоение методологии Microsoft Solutions Framework for Agile Software Development в процессе командной разработки учебной программной системы.
  • Характеристика практикума

    Лабораторный практикум предполагает разбиение группы студентов на команды по 5-7 человек, распределение ролей в каждой команде в соответствии с положениями методологии Microsoft Solutions Framework for Agile Software Development и прохождение каждой командой всех фаз процесса разработки. Практикум состоит из двух разделов.

    В первом разделе (практики 1, 2, 3) повторяются принципы объектного подхода и важные аспекты повторного использования, а также демонстрируется применение унифицированного языка моделирования UML для визуализации проектирования примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных". Здесь же происходит разбиение студентов на команды и формулировка задач.

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

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

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

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

    Содержание практикума

    Практическое занятие №1

    Цель занятия: Повтор принципов объектно-ориентированного подхода.

    Содержание занятия:

    Выполнение объектной декомпозиции на примере задач из курса CS103 "Алгоритмы и структуры данных". Разбор вариантов проектирования.

    Практическое занятие №2

    Цель занятия: Знакомство с построением диаграмм вариантов использования.

    Содержание занятия:

  • Разбиение студентов на команды.
  • Выделение действующих лиц и создание диаграмм вариантов использования на примере задач из курса CS103 "Алгоритмы и структуры данных".
  • Практическое занятие №3

    Цель занятия: Знакомство с построением диаграмм классов.

    Содержание занятия:

  • Переход от диаграмм вариантов использования к диаграммам классов. Создание диаграмм классов на примере задач из курса CS103 "Алгоритмы и структуры данных".
  • Озвучивание кратких постановок задач.
  • Практическое занятие №4

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

    Содержание занятия:

  • Распределение задач между командами.
  • Распределение ролей в командах.
  • Каждая команда:

  • Формирует видение проекта.
  • Выделяет и выполняет оценку рисков.
  • Выявляет и анализирует бизнес-требования.
  • Определяет структуру проекта.
  • Разрабатывает концепцию решения.
  • Практическое занятие №5

    Цель занятия: Прохождение фазы планирования в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Разрабатывает дизайн и архитектуру решения.
  • Создает функциональную спецификацию.
  • Разрабатывает планы проекта.
  • Разрабатывает календарный график проекта.
  • Практическое занятие №6

    Цель занятия: Прохождение фазы разработки в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Создает прототип приложения.
  • Разрабатывает необходимые компоненты решения.
  • Практическое занятие №7

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

    Содержание занятия:

    Каждая команда:

  • Тестирует решение.
  • Практическое занятие №8

    Цель занятия: Прохождение фазы внедрения в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Внедряет решение в эксплуатацию в другую команду.
  • Приложение 1. Постановки задач

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

    Учебный пример для преподавателей

    Система бронирования билетов для авиакомпании

    Краткое описание

    На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.

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

    Анализ постановки - полное описание

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

  • Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.
  • Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.

    Среди причин:

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

  • Менеджер рейсов: должен иметь следующие возможности:
  • создания и удаления аэропортов в системе.
  • создания и удаления рейсов в аэропортах.
  • Задачи, предлагаемые студентам

    Система обработки метеоинформации

    Краткое описание

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

    Полная постановка задачи

    Функционирование системы предполагается на локальном компьютере. Работа в системе должна включать в себя три части:

  • редактирование карт;
  • задание и редактирование движения воздушных масс и циклонов;
  • демонстрация погодных условий.
  • Для редактирования карт и задания движения воздушных масс предполагается, разработка редактора векторной графики. Изображения могут сроиться как из векторных примитивов: линии, окружности, прямоугольники, - так и из более сложных объектов векторной графики: полигоны, кривые Безье, …

    Желательно обеспечить возможность заливки внутренности замкнутых объектов выбранным цветом.

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

    Карта, изображение воздушных масс: набор векторных примитивов.

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

    Режим просмотра изменения метеоусловий: подсистема, которая должна быть реализована в двух видах:

  • интегрированное средство просмотра результата;
  • отдельное приложение просмотра.
  • Система должна уметь сохранять результат работы в определенном формате (рекомендуется XML). Возобновлять состояние после загрузки сохраненных данных, при этом желательно реализовать контроль правильности формата читаемого файла.

    Редактор математических формул

    Краткое описание

    Фирма "OurResearch" занимается написанием математических программ по заказу. При этом в фирме часто приходится писать отчеты заказчику. При написании отчетов заказчик хочет видеть в отчетах математические формулы в классическом виде.

    У Вашей фирмы компания решила заказать удобное средство для перевода и написания математических выражений в разные форматы представления. Причем, если в редакторе присутствует ряд взаимосвязанных формул, то фирма хочет видеть адекватный код. При этом известно, что фирма часто использует C/C++, Pascal и Fortran.

    Полная постановка задачи

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

    Объекты системы: формула, формульный редактор.

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

    Формульный редактор: визуальная часть. Должен позволять:

  • транслировать стандартный синтаксис формул во внутренний формат;
  • отображать из внутреннего формата в графический вид;
  • визуально редактировать формулы;
  • отображать структуру данных формулы.
  • Дополнительно система должна обеспечивать сохранение формул в нескольких форматах (например, в XML).

    Редактор должен включать в себя конвертор в различные форматы, к примеру, перевод формулы в стандартное выражение для C/C++, Pascal и Fortran.

    Также обязательно нужна возможность перевода формулы в BMP-изображение.

    Web-сервис (на основе сокетов)

    Краткое описание

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

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

    Полная постановка задачи

    Web-сервис должен быть рассчитан на небольшое число пользователей и работу в локальной сети. К web-сервису должен быть реализован разделенный доступ пользователей.

    Объекты системы: пользователь, роль, алгоритм, web-сервис.

    Пользователи: логин, пароль, роль.

    Пользователь может на web-сервисе осуществлять следующие действия:

  • размещать алгоритмы;
  • изымать на редактирование алгоритмы;
  • удалять алгоритмы с web-сервиса;
  • исполнять алгоритмы.
  • Роль: представляет собой список пользователей.

    Алгоритм: название, код (математическое выражение), принадлежность пользователю, входные и выходные параметры.

    Web-сервис предоставляет следующие возможности:

  • хранить алгоритмы на сервере;
  • предоставлять доступ к алгоритмам:
  • редактирование;
  • удаление;
  • исполнение алгоритма на сервере.
  • Для хранения алгоритмов на сервере создается дерево каталогов и файлов. Для каждого пользователя создается корневой каталог. В этом каталоге могут храниться, как алгоритмы (файлы с кодом), так и другие каталоги. Разделения прав осуществляется на основе специального файла со списком пользователей, которым доступна эта папка. Права на папку наследуются. Также можно разрешить доступ сразу группе пользователей, принадлежащих определенной роли.

    Редактировать алгоритм может только пользователь, выложивший алгоритм.

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

    Система взаимодействия команд

    Краткое описание

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

    Полная постановка задачи

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

    Система должна удовлетворять следующим требованиям:

  • возможность отправки и получения почты;
  • возможность чата с пользователями, находящимися в сети.
  • Объекты системы: пользователь, сервер, письмо, список контактов, быстрое сообщение, почтовый клиент, клиент для чата.

    Пользователь: ФИО, логин, пароль.

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

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

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

    Список контактов: список логинов пользователей системы.

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

    Клиент для чата: содержит список доступных чатов. Предоставляет возможность создания чатов и открытие чата для людей из списка контактов.

    Учет работы персонала

    Краткое описание

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

    Компания решила изменить данную ситуацию. Вашей компании предложили выработать решение описанной проблемы.

    Полная постановка задачи

    Нужно реализовать систему учета работы персонала.

    Объекты системы: датчики, хранилища данных, менеджер, работник, система начисления зарплаты, система построения отчетов.

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

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

    В системе должны существовать две роли: работник и менеджер. При этом менеджер также может быть и работником.

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

    Менеджер: контролирующая должность. Содержит ФИО, логин, пароль, табельный номер, счет для начисления зарплаты.

    Выполняет следующие функции:

  • Построение и просмотр отчетности по работникам (через систему построения отчетов ).
  • Премирование выделившихся работников.
  • Прием и увольнение персонала.
  • Поднятие и понижение разрядов и определение квалификационной группы.
  • Установление индексов зарплат для работников.
  • Контроль за системой начисления зарплаты.
  • Система начисления зарплаты: для автоматизации необходимо два раза в месяц делать начисление зарплаты работнику. При расчете зарплаты в системе часы, проведенные работником на месте, умножаются на индекс. К полученной сумме прибавляются премиальные и из получившейся суммы вычитаются налоги. Итоговая сумма переводится на счет.

    Система бронирования билетов для авиакомпании

    Краткое описание

    На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. В первой требуется заносить необходимую информацию. Со второй частью будут работать покупатели билетов.

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

    Полная постановка задачи

    Задача является больше математической. Система должна уметь решать трехкритериальную задачу поиска кратчайших путей на графах. Критерии:

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

    Объекты системы: распределенное хранилище рейсов, покупатель билетов.

    Распределенное хранилище рейсов: название рейсов, номера и тип самолетов, класс самолета по комфорту и стоимость билетов.

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

  • Отсутствие рейсов в требуемом направлении даже с пересадками.
  • Сумма слишком мала.
  • Комфорт завышен.
  • В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.

    Система управления проектами

    Краткое постановка

    В компании "SuperSoft" возникла потребность автоматизировать управление проектами. В силу того, что компания существует на рынке разработки ПО недавно и не обладает достаточным количеством свободных финансовых средств, было принято решение не покупать системы управления проектами типа Microsoft Project (стоимость коробочной версии от $600), а разработать собственное простое решение.

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

    Полная постановка задачи

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

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

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

    Исполнитель получает от менеджера задачи, на основании которых для него формируется "ToDo-List". Список может пополняться по ходу проекта, как менеджером, так и самим исполнителем.

    Объекты системы: менеджер, исполнитель, задача, проект, "ToDo-List".

    Менеджер: ФИО, проект(ы).

    Исполнитель: ФИО, проект, "ToDo-List".

    Задача: имя, формулировка, срок начала, срок окончания (выставленный менеджером), срок фактического окончания (когда исполнитель "сдал" задачу менеджеру, а тот ее "принял"), состояние (не начата, выполняется, завершена, отложена), причина изменения срока окончания/откладывания.

    Проект: имя, менеджер, исполнители, задачи.

    "ToDo-List": список задач для исполнителя. Часть списка формируется автоматически, доступна только для чтения. Часть формируется исполнителем "для себя", доступна для редактирования.

    Сроки для задач могут задаваться с точностью до часов (начало: 21 июля 14.00, окончание: 21 июля 16.00, фактического окончание: 21 июля 17 часов, причина изменения сроков: учения по пожарной безопасности).

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

    По данным каждого проекта в системе должна быть возможность поиска.

    Система контроля и распределения ресурсов

    Краткое описание

    Организация "Presentation for you" профессионально занимается подготовкой и проведением презентаций для фирм. В фирме за последние несколько кварталов сильно увеличился объем заказов. В результате постоянно стали наблюдаться ситуации, когда презентации задерживались из-за нехватки каких-либо ресурсов (аудиторий, проекторов, досок).

    В фирме были проведены исследования и было установлено, что ситуация сильно улучшится, если у фирмы появится электронная система распределения ресурсов, а не бумажная как это было раньше.

    Полная постановка задачи

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

    Объекты системы: сервер, ресурс, расписание использования ресурса, пользователь, администратор, менеджер ресурсов, клиент.

    Сервер: Обладает следующей функциональностью:

  • Хранит информацию обо всех ресурсах и пользователях.
  • Позволяет управлять пользовательскими записями:
  • Добавлять.
  • Удалять.
  • Назначать уровень доступа.
  • Разделяет уровень доступа для различных пользователей на основе ролевых кластеров:
  • Администратор.
  • Менеджер.
  • Пользователь.
  • Выдает информацию о ресурсах в соответствии с уровнем доступа.
  • Ресурс: название, серийный номер (номер аудитории, номер доски), расписание использования ресурса.

    Расписание использования ресурсов: порождается для каждого ресурса. Включается записи о времени занятости и цели использования.

    Пользователь: ФИО, логин, пароль, информация о дополнительных ролях.

    Дополнительных ролей две:

  • Администратор.
  • Менеджер ресурсов.
  • У пользователя должны быть следующие функции:

  • Запрос на занятие ресурса на определенное время с указанной целью.
  • Различные виды просмотров занятости ресурсов.
  • Конкретного ресурса.
  • Группы ресурсов.
  • Администратор: Выполняет функции менеджера пользователей. Не может управлять ресурсами.

    Менеджер ресурсов: Основные функции:

  • Добавление и удаление ресурсов.
  • Подтверждение или отклонение запросов на занятие ресурсов.
  • Клиент: Должен быть реализован в виде web-сайта и Windows приложения.

    Страницы:

    1. Цели и задачи курса и его место в учебном процессе

    1.1. Цель преподавания курса

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

    Цель данного курса состоит в изучении основных путей организации и проведения успешных проектов в области разработки программного обеспечения на базе принципов Microsoft Solutions Framework (MSF). Важная роль отводится практической составляющей курса.

    1.2. Задачи изучения курса

    В рамках изучения курса предполагается решение следующих задач:

  • рассмотрение технологических основ процесса разработки программного обеспечения;
  • изучение основ унифицированного языка UML для визуального моделирования элементов предметной области в рамках проектирования программной системы и ее основных компонент;
  • получение практического опыта работы в команде из 5-7 человек с применением методологии MSF;
  • приобретение и развитие навыков анализа, проектирования, документирования и разработки программных комплексов средней сложности.
  • По окончании изучения курса студенты будут уметь использовать методологию Microsoft Solutions Framework for Agile Software Development, включая:

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

    Курс опирается на материалы следующих курсов: CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", CS105 "Дискретная математика" . Предполагается, что данный курс читается параллельно с курсом CS103 "Алгоритмы и структуры данных" с запаздыванием в 1 семестр (рис 1).

    (рис 1) Предполагаемая последовательность изучения курсов. Закрашенные части читаются одновременно

    2. Характеристика курса

    Данный курс читается в 4-ом семестре и опирается на прочитанные ранее общие курсы CS101 "Введение в методы программирования", CS102 "Методы объектно-ориентированного программирования", в рамках которых студенты знакомятся с фундаментальными понятиями, принципами и методами программирования, изучают основные алгоритмы, простейшие структуры данных, языки программирования Object Pascal и C/C++. В 3-ем семестре студенты изучают первую часть курса CS103 "Алгоритмы и структуры данных", выполняют лабораторные работы согласно учебному плану. Таким образом, полученных к 4-му семестру знаний и навыков достаточно для того, чтобы приступить к ознакомлению с технологиями коллективной разработки программ.

    Конечно, уровень студента 2 курса все еще не позволяет овладеть этой темой полностью, поэтому учебный план предполагает изучение нескольких последовательно расположенных курсов, первым из которых, вводным, является данный курс - "Технологии программирования. Курс на базе Microsoft Solutions Framework (MSF)".

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

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

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

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

    Рассмотрим кратко основные разделы курса и их содержание.

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

    Основная часть курса состоит из трех разделов.

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

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

    Во втором разделе курса (лекции 3, практики 1, 2, 3) идет речь о принципах объектно-ориентированного анализа и проектирования программного обеспечения при помощи визуальных средств языка UML. Дается обзор принципов объектного подхода, рассматриваются важные аспекты повторного использования, рассматриваются элементы языка UML. Демонстрируется применение UML для визуализации проектирования лекционных примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных".

    В третьем разделе курса (лекции 4, 5, 6, 7, практики 4, 5, 6, 7, 8) изучается методология разработки программного обеспечения Microsoft Solutions Framework 4.0. Рассматривается история MSF, основные принципы MSF, модель проектной группы, роли и фазы MSF. Через все фазы проводится лекционный пример - разработка системы бронирования билетов для аэропорта.

    3. Содержание курса

    Введение

    Важность предмета.

    Программа и программное обеспечение, основные отличия. О рынке программного обеспечения.

    Сложность управления процессом разработки программного обеспечения.

    Технологии программирования как способ борьбы со сложностью.

    Обзор технологий программирования (структурное, модульное, объектно-ориентированное, компонентное программирование).

    Цели и задачи курса. Структура учебного плана. Основная и дополнительная литература, Интернет-источники.

    1. Элементы программной инженерии.

    1.1. Программная инженерия, основные понятия.

    Инженерия и инженеры.

    Программная инженерия как инженерная дисциплина.

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

    Программные инженеры и их деятельность.

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

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

    1.2. Процесс создания программного обеспечения

    Понятие процесса создания ПО. Основные стадии процесса.

    Модели процесса создания ПО. Каскадная и эволюционная модели.

    Итерационные модели процесса создания ПО. Модель пошаговой разработки, спиральная модель.

    2. Визуальное моделирование при анализе и проектировании. Основы Unified Modeling Language (UML).

    2.1. Анализ и проектирование. Некоторые частные вопросы

    2.1.1. Обзор принципов объектного подхода.

    Алгоритмическая и объектная декомпозиции. Классы и объекты.

    Объектно-ориентированный анализ.

    Объектно-ориентированное проектирование.

    Объектно-ориентированное программирование.

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

    Пример: ООП и структуры данных. Проектирование структуры данных стек.

    2.1.2. Повторное использование.

    Идея повторного использования. Важность повторного использования.

    Достоинства повторного использования. Виды повторного использования.

    2.2. Визуальное моделирование. История языка UML.

    Идея визуального моделирования.

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

    История возникновения и развития языка UML.

    2.3. Структура языка UML.

    Модели UML.

    Диаграммы и понятия UML.

    2.4. Учебный пример: Задача о разработке программного комплекса бронирования билетов для авиакомпании "SRS - Seat Reservation System". Постановка задачи.

    2.5. Визуальное описание модели функционирования системы средствами UML.

    Понятия Актера и Варианта использования.

    Ассоциация между Актером и Вариантом использования.

    Диаграмма вариантов использования.

    Диаграмма действия.

    Пример: Использование средств UML для визуального моделирования поведения программной системы "SRS".

    2.6. Классы, объекты, поля, методы, подсистемы, компоненты, пакеты и их отображение средствами UML.

    Пример: Использование средств UML для визуального проектирования программной системы "SRS".

    2.7. Проектирование системы. Диаграммы классов и их описание средствами UML.

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

    Пример: Использование средств UML для визуального проектирования программной системы "SRS".

    3. Методология создания программных решений Microsoft Solutions Framework.

    3.1. Введение в методологию MSF и историческая справка.

    Что такое MSF. Основные концепции методологии: модель процессов, управление проектом, модель проектной группы, управление рисками. Позиционирование MSF в сравнении с другими методологиями разработки программного обеспечения. Инструментальная поддержка методологии до версии 3.0 включительно. Источники информации.

    3.2. Нововведения версии MSF 4.0.

    Разделение методологии на два направления: MSF for Agile Software Development и MSF for CMMI Process Improvement. Причины разделения методологии MSF на "облегченный" и "тяжелый" варианты, основные отличия направлений. Почему в основу курса положено направление MSF for Agile Software Development? Характеристика основных положений MSF for Agile Software Development. Инструментальная поддержка MSF 4.0 в среде разработки Microsoft Visual Studio 2005. Источники информации.

    3.3. Формирование команды. Модель проектной группы MSF for Agile Software Development.

    Основные принципы построения команды.

    "Проектная группа - команда равных".

    Каждая ролевая группа имеет зону ответственности и защищает интересы заинтересованных лиц из этой зоны.

    "Масштабируемость" модели проектной группы в зависимости от числа участников.

    Ролевые группы и роли, зоны ответственности ролевых групп, их задачи и взаимодействие с заинтересованными лицами.

    MSF for Agile Software Development выделяет 7 ролевых групп: управление программой, архитектура продукта, разработка, тестирование, управление выпуском, удовлетворение потребителя, управление продуктом, - и 6 ролей: менеджер проекта, архитектор, разработчик, тестер, релиз-менеджер, бизнес-аналитик. Для каждой группы и роли, помимо зоны ответственности, в которой роль имеет решающий голос, определены заинтересованные стороны, как внутри, так и вне команды, с которыми группа должна взаимодействовать и чьи интересы представлять/отстаивать при принятии решений.

    Рекомендации по возможному объединению ролей.

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта.

    3.4. Управление рисками в MSF for Agile Software Development.

    Основные сведения о рисках.

    Планирование управления рисками.

    Процесс управления рисками: выявление, анализ и приоритезация, планирование, мониторинг, корректирование, извлечение уроков.

    Управление рисками как составная часть жизненного цикла проекта.

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выделение рисков.

    3.5. Модель процессов MSF for Agile Software Development.

    Принципы модели процессов.

    Взаимодействуйте с "заказчиками".

    Поощряйте свободный обмен информацией в проекте.

    Создавайте "единое видение проекта".

    Следите за качеством продукта.

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

    Ставьте "вехи".

    Будьте готовы к внедрению сегодня.

    Схема процесса разработки.

    Основные структурные единицы схемы: циклы, фазы и вехи.

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

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

    3.6. Старт проекта. Фаза выработки концепции.

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

    Задачи ролевых групп на фазе выработки концепции.

    Главная веха фазы: "Концепция утверждена".

    Рекомендуемые промежуточные вехи: "Ядро проектной группы сформировано", "Черновой вариант концепции проекта составлен".

    Результаты фазы: "Общее описание и рамки проекта", "Документ оценки рисков", "Описание структуры проекта".

    Пример: Задача о разработке программного комплекса бронирования билетов для аэропорта. Выработка концепции.

    3.7. Планирование проекта. Фаза планирования.

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

    Категории проектных требований. Уровни процесса проектирования.

    Задачи ролевых групп на фазе планирования.

    Главная веха фазы: "Планы проекта утверждены".

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

    Результаты фазы: "Функциональная спецификация", "План управления рисками", "Сводный план и сводный календарный график проекта".

    3.8. Разработка решения. Фаза разработки.

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

    Задачи ролевых групп на фазе разработки.

    Главная веха фазы: "Разработка завершена ".

    Рекомендуемые промежуточные вехи: "Концепция подтверждена", "Билд номер N завершен", "Билд номер N+1 завершен",…

    Результаты фазы: "Исходный и исполняемый код приложений", "Скрипты установки и конфигурирования", "Окончательная функциональная спецификация", "Материалы поддержки решения", "Спецификации и сценарии тестов".

    3.9. Стабилизация решения. Фаза стабилизации.

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

    Задачи ролевых групп на фазе стабилизации.

    Главная веха фазы: "Готовность решения утверждена".

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

    Результаты фазы: "Окончательный продукт", "Документация выпуска", "Материалы поддержки решения", "Результаты и инструментарий тестирования", "Исходный и исполнимый код приложений", "Проектная документация", "Анализ пройденной фазы".

    3.10. Внедрение решения. Фаза внедрения.

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

    Задачи ролевых групп на фазе внедрения.

    Главная веха фазы: "Внедрение завершено".

    Рекомендуемые промежуточные вехи: "Ключевые компоненты развернуты", "Внедрение на местах завершено", "Внедренное решение стабилизировано".

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

    4. Затрагиваемые разделы рекомендаций Computing Curricula 2001 (Software Engineering 2004)

    Данный курс является вводным курсом в рамках направления "Программная инженерия" и затрагивает следующие элементы курса SE201:

    CMP.ct - Технологии разработки

    MAA.md - Моделирование

    MAA.tm - Типы моделей

    MAA.rfd - Требования

    MAA.rsd - Спецификация и документирование требований

    MAA.rv - Проверка требований

    DES - Проектирование

    PRO.imp - Процесс разработки

    MGT - Управление процессом разработки

    5. Учебно-методические материалы по курсу

    5.1. Литература

  • И. Соммервиль. Инженерия программного обеспечения, 6 изд. - И.д. "Вильямс", 2002.
  • Г. Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++. Второе издание. - Бином, 1998.
  • N. Wirth. Program Development by Stepwise Refinement // Communications of the ACM vol.26(1).- 1971, 1983.
  • O. Dahl, E. Dijkstra, C.A.R. Hoare. Structured Programming.-London, England: Academic Press, 1972.
  • Р. Лингер, Х. Миллс, Б. Уитт. Теория и практика структурного программирования. - М.: Мир, 1982.
  • Э. Салливан. Время - деньги. - М.:Microsoft Press, Русская редакция, 2002.
  • Г. Буч, Дж. Рамбо, А. Джекобсон. UML. Руководство пользователя. - ДМК-Пресс, Питер, 2004.
  • G. Booch, J. Rumbaugh, I. Jacobson. The Unified Modeling Language Reference Manual - Second Edition, Addison-Wesley, 2004.
  • Модель процессов MSF. Белая книга, 2003, перевод eLine Software.
  • Дисциплина управления рисками MSF. Белая книга, 2003, перевод eLine Software.
  • Модель проектной группы MSF. Белая книга, 2003, перевод eLine Software.
  • 1846A: Microsoft Solutions Framework Essentials. Microsoft Official Course, 2002
  • 2710B: Analyzing Requirements and Defining Microsoft .NET Solutions Architecture. Microsoft Official Course, 2003
  • MSF Process Model. White paper, 2002 Microsoft Corporation.
  • MSF Risk Management Discipline. White paper, 2002 Microsoft Corporation.
  • MSF Team Model. White paper, 2002 Microsoft Corporation.
  • 5.2. Информационные ресурсы сети Интернет

  • Ian Sommerville. Software Engineering. 6th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE6]
  • Ian Sommerville. Software Engineering. 7th Edition. [http://www.comp.lancs.ac.uk/computing/resources/IanS/SE7]
  • http://www.uml.org
  • http://www.wikipedia.org
  • http://www.microsoft.com/msf
  • С. Якимчук. MSF - философия создания IT-решений или голые амбиции лидера, 2004: [http://www.citforum.ru/SE/project/msf/].
  • Алистер Кокбёрн. Каждому проекту своя методология:[http://software-testing.ru/lib/cockburn/methodology-per-project.htm](перевод статьи Alistair Cockburn. Methodology per project: [http://alistair.cockburn.us/index.php/Methodology_per_project]).
  • А. Терехов, А. Ложечкин. Microsoft Solutions Framework 4.0 - опыт Microsoft по организации командной разработки. Презентация с Microsoft Платформа 2006
  • MSF for Agile Software Development Process Guidance: [http://go.microsoft.com/fwlink/?linkid=63524]
  • Цели и задачи лабораторного практикума

    Цель данного лабораторного практикума состоит в практическом знакомстве с процессом командной разработки программного обеспечения на примере Microsoft Solutions Framework (MSF).

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

  • начальное освоение унифицированного языка моделирования UML;
  • получение практического опыта работы в команде из 5-7 человек;
  • освоение методологии Microsoft Solutions Framework for Agile Software Development в процессе командной разработки учебной программной системы.
  • Характеристика практикума

    Лабораторный практикум предполагает разбиение группы студентов на команды по 5-7 человек, распределение ролей в каждой команде в соответствии с положениями методологии Microsoft Solutions Framework for Agile Software Development и прохождение каждой командой всех фаз процесса разработки. Практикум состоит из двух разделов.

    В первом разделе (практики 1, 2, 3) повторяются принципы объектного подхода и важные аспекты повторного использования, а также демонстрируется применение унифицированного языка моделирования UML для визуализации проектирования примеров из читаемого параллельно курса CS103 "Алгоритмы и структуры данных". Здесь же происходит разбиение студентов на команды и формулировка задач.

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

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

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

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

    Содержание практикума

    Практическое занятие №1

    Цель занятия: Повтор принципов объектно-ориентированного подхода.

    Содержание занятия:

    Выполнение объектной декомпозиции на примере задач из курса CS103 "Алгоритмы и структуры данных". Разбор вариантов проектирования.

    Практическое занятие №2

    Цель занятия: Знакомство с построением диаграмм вариантов использования.

    Содержание занятия:

  • Разбиение студентов на команды.
  • Выделение действующих лиц и создание диаграмм вариантов использования на примере задач из курса CS103 "Алгоритмы и структуры данных".
  • Практическое занятие №3

    Цель занятия: Знакомство с построением диаграмм классов.

    Содержание занятия:

  • Переход от диаграмм вариантов использования к диаграммам классов. Создание диаграмм классов на примере задач из курса CS103 "Алгоритмы и структуры данных".
  • Озвучивание кратких постановок задач.
  • Практическое занятие №4

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

    Содержание занятия:

  • Распределение задач между командами.
  • Распределение ролей в командах.
  • Каждая команда:

  • Формирует видение проекта.
  • Выделяет и выполняет оценку рисков.
  • Выявляет и анализирует бизнес-требования.
  • Определяет структуру проекта.
  • Разрабатывает концепцию решения.
  • Практическое занятие №5

    Цель занятия: Прохождение фазы планирования в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Разрабатывает дизайн и архитектуру решения.
  • Создает функциональную спецификацию.
  • Разрабатывает планы проекта.
  • Разрабатывает календарный график проекта.
  • Практическое занятие №6

    Цель занятия: Прохождение фазы разработки в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Создает прототип приложения.
  • Разрабатывает необходимые компоненты решения.
  • Практическое занятие №7

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

    Содержание занятия:

    Каждая команда:

  • Тестирует решение.
  • Практическое занятие №8

    Цель занятия: Прохождение фазы внедрения в каждой команде.

    Содержание занятия:

    Каждая команда:

  • Внедряет решение в эксплуатацию в другую команду.
  • Приложение 1. Постановки задач

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

    Учебный пример для преподавателей

    Система бронирования билетов для авиакомпании

    Краткое описание

    На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. Работа первой части системы связана с занесением информации. Вторая часть системы предназначена для общения с клиентами.

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

    Анализ постановки - полное описание

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

  • Распределенное хранилище рейсов: название рейсов, номера и стоимость билетов.
  • Покупатель: ФИО, сумма. Покупатель задает параметры, связанные с суммой, которую он хочет потратить. Система должна подобрать оптимальный маршрут. При отсутствии прямых маршрутов система должна попробовать найти маршруты с пересадками. Если таковых не находится, система должна сказать, что с такими ограничениями нельзя добраться до места назначения.

    Среди причин:

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

  • Менеджер рейсов: должен иметь следующие возможности:
  • создания и удаления аэропортов в системе.
  • создания и удаления рейсов в аэропортах.
  • Задачи, предлагаемые студентам

    Система обработки метеоинформации

    Краткое описание

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

    Полная постановка задачи

    Функционирование системы предполагается на локальном компьютере. Работа в системе должна включать в себя три части:

  • редактирование карт;
  • задание и редактирование движения воздушных масс и циклонов;
  • демонстрация погодных условий.
  • Для редактирования карт и задания движения воздушных масс предполагается, разработка редактора векторной графики. Изображения могут сроиться как из векторных примитивов: линии, окружности, прямоугольники, - так и из более сложных объектов векторной графики: полигоны, кривые Безье, …

    Желательно обеспечить возможность заливки внутренности замкнутых объектов выбранным цветом.

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

    Карта, изображение воздушных масс: набор векторных примитивов.

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

    Режим просмотра изменения метеоусловий: подсистема, которая должна быть реализована в двух видах:

  • интегрированное средство просмотра результата;
  • отдельное приложение просмотра.
  • Система должна уметь сохранять результат работы в определенном формате (рекомендуется XML). Возобновлять состояние после загрузки сохраненных данных, при этом желательно реализовать контроль правильности формата читаемого файла.

    Редактор математических формул

    Краткое описание

    Фирма "OurResearch" занимается написанием математических программ по заказу. При этом в фирме часто приходится писать отчеты заказчику. При написании отчетов заказчик хочет видеть в отчетах математические формулы в классическом виде.

    У Вашей фирмы компания решила заказать удобное средство для перевода и написания математических выражений в разные форматы представления. Причем, если в редакторе присутствует ряд взаимосвязанных формул, то фирма хочет видеть адекватный код. При этом известно, что фирма часто использует C/C++, Pascal и Fortran.

    Полная постановка задачи

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

    Объекты системы: формула, формульный редактор.

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

    Формульный редактор: визуальная часть. Должен позволять:

  • транслировать стандартный синтаксис формул во внутренний формат;
  • отображать из внутреннего формата в графический вид;
  • визуально редактировать формулы;
  • отображать структуру данных формулы.
  • Дополнительно система должна обеспечивать сохранение формул в нескольких форматах (например, в XML).

    Редактор должен включать в себя конвертор в различные форматы, к примеру, перевод формулы в стандартное выражение для C/C++, Pascal и Fortran.

    Также обязательно нужна возможность перевода формулы в BMP-изображение.

    Web-сервис (на основе сокетов)

    Краткое описание

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

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

    Полная постановка задачи

    Web-сервис должен быть рассчитан на небольшое число пользователей и работу в локальной сети. К web-сервису должен быть реализован разделенный доступ пользователей.

    Объекты системы: пользователь, роль, алгоритм, web-сервис.

    Пользователи: логин, пароль, роль.

    Пользователь может на web-сервисе осуществлять следующие действия:

  • размещать алгоритмы;
  • изымать на редактирование алгоритмы;
  • удалять алгоритмы с web-сервиса;
  • исполнять алгоритмы.
  • Роль: представляет собой список пользователей.

    Алгоритм: название, код (математическое выражение), принадлежность пользователю, входные и выходные параметры.

    Web-сервис предоставляет следующие возможности:

  • хранить алгоритмы на сервере;
  • предоставлять доступ к алгоритмам:
  • редактирование;
  • удаление;
  • исполнение алгоритма на сервере.
  • Для хранения алгоритмов на сервере создается дерево каталогов и файлов. Для каждого пользователя создается корневой каталог. В этом каталоге могут храниться, как алгоритмы (файлы с кодом), так и другие каталоги. Разделения прав осуществляется на основе специального файла со списком пользователей, которым доступна эта папка. Права на папку наследуются. Также можно разрешить доступ сразу группе пользователей, принадлежащих определенной роли.

    Редактировать алгоритм может только пользователь, выложивший алгоритм.

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

    Система взаимодействия команд

    Краткое описание

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

    Полная постановка задачи

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

    Система должна удовлетворять следующим требованиям:

  • возможность отправки и получения почты;
  • возможность чата с пользователями, находящимися в сети.
  • Объекты системы: пользователь, сервер, письмо, список контактов, быстрое сообщение, почтовый клиент, клиент для чата.

    Пользователь: ФИО, логин, пароль.

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

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

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

    Список контактов: список логинов пользователей системы.

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

    Клиент для чата: содержит список доступных чатов. Предоставляет возможность создания чатов и открытие чата для людей из списка контактов.

    Учет работы персонала

    Краткое описание

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

    Компания решила изменить данную ситуацию. Вашей компании предложили выработать решение описанной проблемы.

    Полная постановка задачи

    Нужно реализовать систему учета работы персонала.

    Объекты системы: датчики, хранилища данных, менеджер, работник, система начисления зарплаты, система построения отчетов.

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

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

    В системе должны существовать две роли: работник и менеджер. При этом менеджер также может быть и работником.

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

    Менеджер: контролирующая должность. Содержит ФИО, логин, пароль, табельный номер, счет для начисления зарплаты.

    Выполняет следующие функции:

  • Построение и просмотр отчетности по работникам (через систему построения отчетов ).
  • Премирование выделившихся работников.
  • Прием и увольнение персонала.
  • Поднятие и понижение разрядов и определение квалификационной группы.
  • Установление индексов зарплат для работников.
  • Контроль за системой начисления зарплаты.
  • Система начисления зарплаты: для автоматизации необходимо два раза в месяц делать начисление зарплаты работнику. При расчете зарплаты в системе часы, проведенные работником на месте, умножаются на индекс. К полученной сумме прибавляются премиальные и из получившейся суммы вычитаются налоги. Итоговая сумма переводится на счет.

    Система бронирования билетов для авиакомпании

    Краткое описание

    На рынок вышла новая авиакомпания "GlobalAvia". Менеджеры компании решили заказать у вашей фирмы разработку системы бронирования билетов. При заказе фирма поставила ряд условий, которые обязательно должны быть выполнены. В первой версии системы они хотят видеть две части. В первой требуется заносить необходимую информацию. Со второй частью будут работать покупатели билетов.

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

    Полная постановка задачи

    Задача является больше математической. Система должна уметь решать трехкритериальную задачу поиска кратчайших путей на графах. Критерии:

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

    Объекты системы: распределенное хранилище рейсов, покупатель билетов.

    Распределенное хранилище рейсов: название рейсов, номера и тип самолетов, класс самолета по комфорту и стоимость билетов.

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

  • Отсутствие рейсов в требуемом направлении даже с пересадками.
  • Сумма слишком мала.
  • Комфорт завышен.
  • В ответ, пользователь должен иметь возможность поменять параметры с учетом предыстории.

    Система управления проектами

    Краткое постановка

    В компании "SuperSoft" возникла потребность автоматизировать управление проектами. В силу того, что компания существует на рынке разработки ПО недавно и не обладает достаточным количеством свободных финансовых средств, было принято решение не покупать системы управления проектами типа Microsoft Project (стоимость коробочной версии от $600), а разработать собственное простое решение.

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

    Полная постановка задачи

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

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

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

    Исполнитель получает от менеджера задачи, на основании которых для него формируется "ToDo-List". Список может пополняться по ходу проекта, как менеджером, так и самим исполнителем.

    Объекты системы: менеджер, исполнитель, задача, проект, "ToDo-List".

    Менеджер: ФИО, проект(ы).

    Исполнитель: ФИО, проект, "ToDo-List".

    Задача: имя, формулировка, срок начала, срок окончания (выставленный менеджером), срок фактического окончания (когда исполнитель "сдал" задачу менеджеру, а тот ее "принял"), состояние (не начата, выполняется, завершена, отложена), причина изменения срока окончания/откладывания.

    Проект: имя, менеджер, исполнители, задачи.

    "ToDo-List": список задач для исполнителя. Часть списка формируется автоматически, доступна только для чтения. Часть формируется исполнителем "для себя", доступна для редактирования.

    Сроки для задач могут задаваться с точностью до часов (начало: 21 июля 14.00, окончание: 21 июля 16.00, фактического окончание: 21 июля 17 часов, причина изменения сроков: учения по пожарной безопасности).

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

    По данным каждого проекта в системе должна быть возможность поиска.

    Система контроля и распределения ресурсов

    Краткое описание

    Организация "Presentation for you" профессионально занимается подготовкой и проведением презентаций для фирм. В фирме за последние несколько кварталов сильно увеличился объем заказов. В результате постоянно стали наблюдаться ситуации, когда презентации задерживались из-за нехватки каких-либо ресурсов (аудиторий, проекторов, досок).

    В фирме были проведены исследования и было установлено, что ситуация сильно улучшится, если у фирмы появится электронная система распределения ресурсов, а не бумажная как это было раньше.

    Полная постановка задачи

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

    Объекты системы: сервер, ресурс, расписание использования ресурса, пользователь, администратор, менеджер ресурсов, клиент.

    Сервер: Обладает следующей функциональностью:

  • Хранит информацию обо всех ресурсах и пользователях.
  • Позволяет управлять пользовательскими записями:
  • Добавлять.
  • Удалять.
  • Назначать уровень доступа.
  • Разделяет уровень доступа для различных пользователей на основе ролевых кластеров:
  • Администратор.
  • Менеджер.
  • Пользователь.
  • Выдает информацию о ресурсах в соответствии с уровнем доступа.
  • Ресурс: название, серийный номер (номер аудитории, номер доски), расписание использования ресурса.

    Расписание использования ресурсов: порождается для каждого ресурса. Включается записи о времени занятости и цели использования.

    Пользователь: ФИО, логин, пароль, информация о дополнительных ролях.

    Дополнительных ролей две:

  • Администратор.
  • Менеджер ресурсов.
  • У пользователя должны быть следующие функции:

  • Запрос на занятие ресурса на определенное время с указанной целью.
  • Различные виды просмотров занятости ресурсов.
  • Конкретного ресурса.
  • Группы ресурсов.
  • Администратор: Выполняет функции менеджера пользователей. Не может управлять ресурсами.

    Менеджер ресурсов: Основные функции:

  • Добавление и удаление ресурсов.
  • Подтверждение или отклонение запросов на занятие ресурсов.
  • Клиент: Должен быть реализован в виде web-сайта и Windows приложения.

    Вернуться к учебному плану