
- •Федеральное агентство по образованию
- •«Тюменский государственный нефтегазовый университет»
- •Тюмень - 2011
- •1. Анализ предметной области
- •1.1 Описание объекта автоматизации
- •1.1.2 Анализ рынка
- •IntraService
- •1.2. Моделирование бизнес-процессов
- •1.2.1 Словесное описание бизнес-процесса
- •1.2.2 Моделирование бизнес-процесса в методологии idef0
- •2. Постановка задачи
- •2.1 Характеристика комплекса задач
- •2.1.1 Назначение комплекса задач
- •2.1.2 Автоматизируемые функции
- •2.2 Выходная информация
- •2.3 Входная информация
- •2.4 Требования к обеспечивающим подсистемам
- •2.4.1 Требования к информационному обеспечению
- •2.4.2 Требования к программному обеспечению
- •2.4.3 Требования к техническому обеспечению
- •3. Проектирование информационного обеспечения
- •3.1 Описание внешнего информационного обеспечения
- •3.2 Разработка структуры внешнего информационного обеспечения
- •3.2.1. Идентификация информационного пространства
- •3.2.2. Структурирование информационного пространства
- •4. Проектирование программного обеспечения
- •4.1 Описание процесса разработки
- •4.2. Требования к программному обеспечению
- •4.3. Выбор архитектры системы
3. Проектирование информационного обеспечения
3.1 Описание внешнего информационного обеспечения
Внешнее информационное обеспечение включает:
Информацию о пользователях, их счетах, адресах и проч. и информацию, необходимую для их идентификации в системе;
Информацию об устройствах, их адресах, моделях и проч. и информацию, необходимую для их идентификации в системе;
3.2 Разработка структуры внешнего информационного обеспечения
3.2.1. Идентификация информационного пространства
Информационная система, автоматизирующая работу службы Service Desk для эффективной работы должна хранить следующую информацию:
-
Информация об абонентах провайдера;
-
Информация об адресах, на которых предоставляет услуги провайдер;
-
Информация об устройствах, обеспечивающих работу сети провайдера;
-
Журнал обращений от абонентов (журнал инцидентов);
-
Журнал неполадок в сети провайдера (журнал проблем);
-
Эта информация необходима для анализа и составления отчетности для руководства предприятия о работе отделов предприятия с клиентами и между собой.
-
Информация об передачах инцидентов и проблем;
-
Информация об эскалациях инцидентов и проблем;
-
Информация об оперативных группах, образованных для решения инцидентов и проблем;
3.2.2. Структурирование информационного пространства
==========================================================
ТУТ КУСОК ИЗ КУРСОВОЙ ПО БАЗАМ ДАННЫХ С ЕР-МОДЕЛИРОВАНИЕМ
==========================================================
4. Проектирование программного обеспечения
4.1 Описание процесса разработки
При разработке ИС Mithril были применены следующие техники методологии экстремального программирования (eXtreme Programming - XP):
-
Заказчик всегда рядом - «Заказчик» в XP — это не тот, кто оплачивает счета, а тот, кто на самом деле использует систему. XP утверждает, что заказчик должен быть всё время на связи и доступен для вопросов.
-
Рефакторинг - методика улучшения кода, без изменения его функциональности. XP подразумевает, что однажды написанный код в процессе работы над проектом почти наверняка будет неоднократно переделан. Разработчики XP безжалостно переделывают написанный ранее код для того, чтобы улучшить его. Этот процесс называется рефакторингом. Отсутствие тестового покрытия провоцирует отказ от рефакторинга, в связи с боязнью поломать систему, что приводит к постепенной деградации кода.
-
Частые небольшие релизы
-
Стандарты кодирования
Все члены команды в ходе работы должны соблюдать требования общих стандартов кодирования. Благодаря этому:
-
члены команды не тратят время на глупые споры о вещах, которые фактически никак не влияют на скорость работы над проектом;
-
обеспечивается эффективное выполнение остальных практик.
Парное программирование - Парное программирование предполагает, что весь код создается парами программистов, работающих за одним компьютером. Один из них работает непосредственно с текстом программы, другой просматривает его работу и следит за общей картиной происходящего. При необходимости клавиатура свободно передается от одного к другому. В течение работы над проектом пары не фиксированы: рекомендуется их перемешивать, чтобы каждый программист в команде имел хорошее представление о всей системе. Таким образом, парное программирование усиливает взаимодействие внутри команды.
Коллективное владение - каждый член команды несёт ответственность за весь исходный код. Таким образом, каждый вправе вносить изменения в любой участок программы. Парное программирование поддерживает эту практику: работая в разных парах, все программисты знакомятся со всеми частями кода системы. Важное преимущество коллективного владения кодом в том, что оно ускоряет процесс разработки, поскольку при появлении ошибки её может устранить любой программист.
Так же было использовано много приемов методологии Agile, основные идеи которой представлены ниже:
-
Личности и их взаимодействия важнее, чем процессы и инструменты;
-
Работающее программное обеспечение важнее, чем полная документация;
-
Сотрудничество с заказчиком важнее, чем контрактные обязательства;
-
Реакция на изменения важнее, чем следование плану.
Помимо этого были использованы техники бережливой разработки ПО (семейство Agile):
Исключение затрат - Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.
-
Акцент на обучении - короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
-
Предельно отсроченное принятие решений - решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
-
Предельно быстрая доставка заказчику - Короткие итерации.