46
1. Определение целей.
2. Оценка и разрешение рисков.
3. Разработка и тестирование.
4. Планирование следующей итерации.
Рассмотрим риски, которые могут возникнуть на перечисленных этапах:
1. Дефицит специалистов [9]. Этот вид риска присутствует в любом проекте
по разработке программного обеспечения. В него включены такие непредвиденные
обстоятельства, как больничный или нетрудоспособность по другим причинам. План
реагирования на этот вид риска разрабатывается на стадии планирования проекта.
Полностью обезопасить проект от этого риска невозможно, однако, необходимо
осуществить заранее поиск специалистов, которые могут заменить отсутствующего
специалиста или заложить в бюджет проекта сумму на сверхурочную работу
существующей проектной команды.
2. Нереалистичные сроки и бюджет [14]. При планировании проекта
необходимо осуществить расчет длительности проекта с помощью метода «Pert»,
который предполагает три вида длительности задач проекта: пессимистической,
ожидаемой и оптимистической. С помощью оценки вероятностей рассчитывается
длительность работ проекта. В срок выполнения проекта необходимо включать запас,
который может потребоваться при непредвиденных обстоятельствах. Бюджет проекта
рассчитывается по тому же принципу. В нем должен содержаться запас денежных
средств, которые могут понадобиться для покрытия последствий осуществления того
или иного риска.
3. Реализация несоответствующей функциональности. На этапе
планирования проекта необходимо составить техническое задание на создание
системы. Техническое задание должно составляться специалистами (системными
аналитиками) и быть согласовано с экспертами: разработчиками программного
обеспечения и программистами. Подписанное заказчиком и утвержденное экспертной
группой техническое задание поможет избежать риска несоответствующей
функциональности.
4. Разработка неправильного пользовательского интерфейса. Требования к
пользовательскому интерфейсу необходимо описать в разделе «Эскизный проект»
технического задания, которое утверждается заказчиком. Все пожелания заказчика,
47
которые не входят в техническое задание реализуются дополнительно после сдачи
проекта системы.
5. «Золотая сервировка», перфекционизм, ненужная оптимизация и
оттачивание деталей. На каждом этапе проекта назначается ответственное лицо,
которое отвечает за качество работы на текущей стадии. Менеджер проекта
контролирует как промежуточные, так и итоговый результат каждого этапа.
6. Непрекращающийся поток изменений. На этапе составления технического
задания на создание системы должны быть учтены и зафиксированы все требования к
разрабатываемой системе. Все пожелания заказчика, которые не входят в техническое
задание реализуются дополнительно после сдачи проекта системы.
7. Нехватка информации о внешних компонентах, определяющих
окружение системы или вовлечённых в интеграцию. Ответственность за неполноту
сведений, предоставленных на стадии планирования проекта несет заказчик проекта.
8. Недостатки в работах, выполняемых внешними (по отношению к проекту)
ресурсами. Этот риск должен учитываться на стадии планирования проекта, поскольку
могут потребоваться дополнительные временные ресурсы для устранения выявленных
недостатков.
9. Недостаточная производительность получаемой системы.
Производительность системы рассчитывается на этапе составления технического
задания, поэтому оно должно утверждаться не только заказчиком, но и экспертами в
области разработки программного обеспечения.
10. Разрыв между квалификацией специалистов и требованиями проекта.
Необходимо учитываться этот риск на этапе планирования проекта. И осуществлять
формирование проектной команды после формирования всех требований к проекту.
Иначе потребуется дополнительный бюджет и временные затраты на привлечение
специалистов в подходящей квалификацией.
Большая часть этих рисков связана с организационными и процессными
аспектами взаимодействия специалистов в проектной команде. Качество управления
рисками проекта зависит от квалификации менеджера проекта.
48
2.1.3. Организационно-правовые и программно-аппаратные средства обеспечения
информационной безопасности и защиты информации
Рассмотрим аспекты реализации информационной безопасности для
поставленной задачи. Защита системы от внутренних угроз предполагает добавление в
существующую Политику безопасности организации раздела о разграничении прав
доступа к разрабатываемой системе [5]. Пользователями системы будет весь
преподавательский состав учреждения и ученики школы. Поэтому доступ к
реализуемой системе должен быть у всех перечисленных лиц. Права на создание тестов
должны быть только у преподавательского состава учреждения. Права на удаление
теста должны быть только у того педагога, который его создал и у администратора
системы. У учеников школы должны быть права на доступ к тестам и созданию бланка
ответов. Все изменения в системе должны протоколироваться для возможности
выявления лица, нарушившего Политику безопасности.
Защита системы от внешних угроз будет реализована с помощью текущей
Политики безопасности организации: на серверное оборудование учреждения не
установлены сторонние средства удаленного администрирования. Доступ к серверу
осуществляется с помощью «Remote desktop protocol», в том числе и сервер
приложений и СУБД, где будет установлена серверная версия разрабатываемой
информационной системы. Доступ к серверу осуществляется только авторизованный.
Определим правила разграничения доступа к разрабатываемой системе. Для
того, чтобы определить правила разграничения доступа, выделим группы
пользователей, которые будут работать с разрабатываемой системой:
1. Администратор.
2. Учитель.
3. Ученик.
Затем составим список разделов системы и опишем права доступа для каждой
категории пользователей. Права доступа представлены в таблице 8.
Таблица 8
Разграничение прав доступа
Раздел
Администратор
Ученик
Учитель
49
Справочники
Создание,
редактирование,
удаление
-
Просмотр
Тесты
Просмотр
Создание,
редактирование
Бланки
ответов
Удаление
Создание
Просмотр
2.2. Информационное обеспечение задачи
2.2.1. Информационная модель и её описание
Составим информационную модель задачи и дадим ее описание.
Информационная модель включает в себя 4 справочника: Учитель, Ученик, Предмет и
тип вопроса. Помимо этого, база данных информационной системы будет включать в
себя следующие таблицы: Класс, Тест, Вопрос, Вариант ответа, Бланк ответа,
Пользователь и Право доступа. Данные в информационную систему будут вводиться
следующими пользователями: Администратор, Учитель и Ученик с помощью
следующих форм приложения: форм справочников, форм теста и формы бланка
ответов. В результате работы с системой будет формироваться отчет по проведенной
проверке знаний, который доступен только учителю. Информационная модель
представлена на рисунке 13.
ИС
Спр.
«Ученик»
Спр.
«Предмет»
Т. «Вопрос»
Спр.
«Учитель»
Администратор
Форма
справочника
Форма бланка
ответов
Спр. «Тип
вопроса»
Спр.
«Ученик»*
Спр.
«Учитель»*
Спр.
«Вопрос»*
Спр. «Тип
вопроса»*
Спр.
«Предмет»*
Учитель
Форма теста
Т. «Класс»
Т. «Бланк
ответа»
Т. «Бланк
ответа»*
Т. «Право
доступа»*
Т.
«Пользователь»
Т. «Право
доступа»
Т. «Тест»
Т. «Вариант
ответа»
Т. «Вариант
ответа»*
Т.
«Класс»*
Т. «Тест»*Т. «Пользователь»*
Учитель Ученик
Отчет по
проведенной
проверке знаний
Рисунок 13. Информационная модель
50
2.2.2. Характеристика нормативно-справочной, входной и оперативной информации
Рассмотрим состав входной информации. Входными документами процесса
являются:
• Учебная программа;
• Методические пособия.
Согласно перечисленным документам осуществляется создание тестового
материала.
Оперативной информацией процесса являются тесты и бланки ответов. Тест
представляет собой комплекс вопросов по заданным темам разного типа. Тесты не
имеют унифицированной формы, поэтому потребуется оригинальное проектирование
формы теста.
Бланк ответов содержит следующую информацию: фамилию и имя ученика,
класс, номера вопросов и варианты ответов на них. Как правило, ответы на вопросы
записываются в табличной форме. Бланк ответов не имеет унифицированную форму, в
связи с чем необходимо спроектировать оригинальную форму бланка.
В проектируемой информационной системе должны быть следующие
справочники:
1. Учитель.
2. Ученик.
3. Тип вопроса.
4. Предмет.
Характеристика справочников представлена в таблице 9.
Таблица 9
Характеристика справочников
Характеристика
Учитель
Ученик
Предмет
Тип
вопроса
Ответственный за
ведение
Администратор
Объем справочника
в записях
120
1200
20
4
Частота
актуализации
По мере необходимости
Объем актуализации
5%
Характеристика
Учитель
Ученик
Предмет
Тип
вопроса
Реквизитный состав
Фамилия
Фамилия
Наименован
ие
Наименован
ие
Имя
Имя
51
Отчество
Отчество
Дата
рождения
Для каждого из описанных справочников разработаем экранную форму для
ввода данных. Экранная форма справочника «Учитель» представлена на рисунке 14.
Рисунок 14. Экранная форма справочника «Учитель»
На рисунке 15 представлена экранная форма справочника «Ученик».
Рисунок 15. Экранная форма справочника «Ученик»
На рисунке 16 представлена экранная форма справочника «Предмет».
52
Рисунок 16. Экранная форма справочника «Предмет»
На рисунке 17 представлена экранная форма справочника «Тип вопроса».
Рисунок 17. Экранная форма справочника «Тип вопроса»
53
2.2.3. Характеристика результатной информации
Результатная информация процесса содержится в отчете о проведенной
проверке текущих знаний учеников. В отчете перечислены следующие данные:
1. Предмет.
2. Класс.
3. ФИО учителя.
4. Количество оценок «Отлично».
5. Количество оценок «Хорошо».
6. Количество оценок «Удовлетворительно».
7. Количество оценок «Неудовлетворительно».
8. Общее количество учеников, написавших тест.
9. Вопросы, на которые было дано наибольшее количество неверных
ответов.
Результатная информация хранится в следующих таблицах базы данных:
1. Учитель.
2. Предмет.
3. Класс.
4. Бланк ответов.
5. Вопрос.
6. Вариант ответа.
Характеристика перечисленных таблиц представлена в таблице 10.
Таблица 10
Характеристика таблиц с результативной информацией
Наименование таблицы
Наименование поля
Учитель
Фамилия
Имя
Отчество
Предмет
Наименование
Класс
Номер
Буква
Бланк ответов
Дата
Вопрос
Номер
Вариант ответа
Номер
Для отчета с результатной информацией необходимо создать наглядную и
понятную форму. Экранная форма отчета по результатам проведенной проверки
текущих знаний представлена на рисунке 18.
54
Рисунок 18. Экранная форма отчета по проверке текущих знаний
2.3. Программное обеспечение задачи
2.3.1. Общие положения (дерево функций и сценарий диалога)
Для того, чтобы привести иерархию функций управления и обработки данных,
которые будут автоматизированы с помощью проектируемой ИС, необходимо
выделить и детализировать два подмножества функций [8]:
1. Функции, реализующие служебные функции.
2. Функции, реализующих основные функции управления и обработки
данных.
Выявление состава функций, их иерархии и выбора языка общения (например,
главное меню ИС) позволит разработать структуру сценария диалога, который даст
возможность определить состав кадров диалога, содержание каждого кадра и их
соподчиненность.
Разработаем дерево функций системы, согласно приведенным рекомендациям.
К основным функциям разрабатываемой системы относятся:
55
1. Редактирование справочников.
2. Разработка тестов.
3. Заполнение бланков ответов.
4. Формирование отчетности.
К служебным функциям разрабатываемой ИС относятся:
1. Настройка системы.
2. Управление окнами.
3. Помощь по работе программы.
Дерево функций представлено на рисунке 19.
Функции
Основные Служебные
Редактирование
справочников
Разработка тестов
Настройка
программы
Управление окнами
Руководство
пользователя
Заполнение бланков
ответов
Формирование
отчетов
Рисунок 19. Дерево функций системы
При разработке структуры диалога необходимо предусмотреть возможность
работы с экранными формами справочников, формирование выходных документов,
корректировки вводимых данных, просмотра введенной информации, работу с
таблицами нормативно-справочной информации, протоколирования действий
пользователя, а также помощь на всех этапах работы [15].
Разработаем сценарий диалога информационной системы. Сценарий диалога
представлен на рисунке 20.