Методология проектирования и разработки программ

Министерство образования и науки Российской Федерации
Московский физико-технический институт
(государственный университет)
УТВЕРЖДАЮ
Проректор по учебной работе
____________Ю. А. Самарский
«____» _____________ 2005 г.
ПРОГРАММА
по курсу: МЕТОДОЛОГИЯ ПРОЕКТИРОВАНИЯ И
РАЗРАБОТКИ ПРОГРАММ
по направлению: 511600
факультеты: ФУПМ, ФАКИ
кафедра: ИНФОРМАТИКИ
курс: 5
курсовая работа: 9 семестр
семестр: 9
экзамен: 9 семестр
практические занятия: 34 часа
ВСЕГО ЧАСОВ: 88
Программу составил ст. преподаватель Ю.В. Блажевич
Программа обсуждена на заседании
кафедры информатики
14 января 2005 г.
Заведующий кафедрой,
профессор
И.Б. Петров
1. Введение. Обзор CMM, USDP, XP
2. Основные положения USDP:
а) процесс, управляемый требованиями заказчика
b) всё основано на архитектуре
c) инкрементальность и итеративность.
3. Бизнес модель системы. Понимание системы через бизнес
модель.
4. Требования заказчика как use-case модель. Для чего нужен
системный аналитик. Дизайн интерфейсов на раннем этапе.
5. Аналитическая модель – первое представление системы на
техническом языке. Анализ use-case модели. Архитектура
системы. Зачем нужна аналитическая модель.
6. Дизайн модель – от абстракций в классам – последний штрих
перед реализацией. Модель распределения системы по
физическим узлам.
7. Реализация. Интеграция системы.
8. Тестирование. Виды тестов. Почему тест инженер должен
работать с самого начала проекта.
Переход
от
waterfall
процесса
к
итеративному
инкрементальному.
Задачи для практикума
Основная и единственная задача, которая может показать
усвоение данного курса, является создание системы,
автоматизирующей какой-либо процесс. Предлагается создание
системы автоматизации документооборота деканата и/или
кафедры. Задача выполняется командой из нескольких человек.
На каждой итерации производится тестирование и сдача
заказчику. Составление одной модели должно быть разбито на
несколько итераций. Сдача преподавателю производится по
этапам.
Этапы соответствуют моделям процесса:
Бизнес-модель. Для составления этом модели необходима
беседовать с представителем автоматизируемого «производства»,
т.е. поговорить с секретарём деканата/кафедры на предмет
неавтоматизированного «бумажного» труда.
Use-case модель. Составляется на основе бизнес модели
полученную use-case модель необходимо утвердить у заказчика
(секретаря деканата/кафедры).
2
Аналитическая модель. Выполняется на основе use-case модели.
Должна содержать в себе, помимо всего прочего, разбиение на
модули и проработанную архитектуру приложения, которая не
будет меняться уже до конца.
Дизайн-модель. Выполняется на основе аналитической модели.
Должна содержать в себе полную диаграмму классов, разбитых
на модули, и все динамические диаграммы.
Реализация выполняется на основе дизайн модели одним
человеком.
Тестирование выполняется на каждой итерации. Работа тестинженера начинается на этапе аналитической модели для
внесения в архитектуру требований, необходимых для
тестирования приложения.
СПИСОК ЛИТЕРАТУРЫ
1. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон.
Унифицированный процесс разработки программного
обеспечения. Питер, 2002. ISBN 5-318-00358-3
2. Грейди Буч, Джеймс Рамбо, Айвар Джекобсон. UML.
Руководство пользователя. ДМК, 2000. ISBN 5-93700-009-9
3. Грейди Буч. Объектно - ориентированный анализ и
проектирование с примерами приложений на С++.
Бином, Невский Диалект, 1998. ISBN 0-8053-5340-2, 5-79890067-3, 5-7940-0017-1
4. IBM Rational Software. http://www.rational.com
5. Extreme Programming (XP).
http://www.extremeprogramming.org
6. Capability Maturity Model® for Software.
http://www.sei.cmu.edu/cmm/cmm.html
3