37
этапы, причем переход от одного этапа к следующему этапу выполняется только
после того, как будет полностью завершена работа на текущем этапе (рис. 2.1).
Каждый этап завершается выпуском полного комплекта документации, который
достаточен для того, чтобы разработка могла быть продолжена другой командой
разработчиков.
Рис. 2.1 Каскадная схема разработки
Преимущества каскадного подхода:
на каждом этапе формируется полный набор проектной документации,
который отвечает критериям полноты и согласованности;
выполняемые в логичной последовательности этапы работ позволяют
планировать сроки завершения всех работ, а также соответствующие
затраты [17. стр.18].
Каскадный подход хорошо зарекомендовал себя при построении ИС, для
которых в самом начале разработки можно достаточно точно и полно
сформулировать все основные требования, с тем, чтобы предоставить
разработчикам свободу реализовать данные требования как можно лучше с
технической точки зрения.
Недостатки каскадного подхода:
реальный процесс создания систем никогда полностью не укладывается в
такую жесткую схему;
возникает постоянная потребность в возврате к предыдущим этапам и
уточнении или пересмотре ранее принятых решений;
существенное запаздывание с получением результатов;
38
большие затраты на разработку ПО.
Спиральная модель ЖЦ делает упор на начальные этапы ЖЦ, т.е. анализ и
проектирование. На данных этапах реализуемость технических решений
проверяется посредством создания прототипа. Каждый виток спирали
соответствует созданию некоторого фрагмента или версии ПО, на нем
уточняются цели и характеристики проекта, а также определяется его качество и
планируются работы следующего витка спирали. Таким образом, в процессе
разработки выполняется углубление, последовательная конкретизация деталей
проекта и в результате выбирается обоснованный вариант, который уже
доводится до окончательной реализации [12].
Разработка системы итерациями отражает объективно существующий
спиральный цикл создания ИС. Неполное завершение работ на каждом этапе
разработки позволяет переходить на следующий этап, при этом не дожидаясь
полного завершения работы на текущем этапе. При итеративном способе
разработки всю недостающую работу можно выполнить на следующей
итерации. Главная задача: как можно быстрее показать пользователям ИС
работоспособный продукт, при этом активизируя процесс уточнения и
дополнения требований.
Основной проблемой спирального цикла является определение
наилучшего момента перехода на следующий этап. Для решения данной
проблемы необходимо ввести временные ограничения на каждый из этапов ЖЦ.
Переход между этапами осуществляется в соответствии с планом, даже если не
вся запланированная работа закончена. План составляется на основе
статистических данных, которые получены в предыдущих проектах, и личного
опыта разработчиков.
На рис. 2.2 представлено графическое изображение спиральной модели
ЖЦ ИС.
Наиболее оптимальным для нас является выбор спиральной модели, так
как в данной модели были учтены все недостатки каскадной и задачной модели.
При этом в рамках доработки уже существующей ИС часто возникают новые
39
замечания от пользователей, которые можно реализовать на новом витке
спиральной модели.
Рис. 2.2 Спиральная модель ЖЦ ИС [20].
2.1.2 Ожидаемые риски на этапах жизненного цикла и их
описание
Стандарт MSF предоставляет некоторую гарантию минимизации рисков,
потому что весь ЖЦ проекта разделен на несколько этапов, при этом на каждом
этапе есть роли, за которыми закреплены цели для достижения. Однако на
каждой фазе выполнения проекта присутствуют определенные риски.
Так, например, в фазе выработки концепции могут возникать следующие
риски:
недальновидный анализ сроков проекта и его бюджета (необходимо
более детальное прорабатывание задачи и цели проекта, определение
большего количества контрольных точек);
неправильно подобранный проектный состав исполнителей может
повлечь за собой отсутствие командной работы (необходим более
тщательный подбор специалистов в проектную группу).
На фазе планирования могут возникнуть следующие риски:
не корректно сформированная архитектура используемого решения.
В фазе разработки возможны следующие риски:
40
неправильная интерпретация технического задания (ТЗ) и, как следствие,
неправильное программирование архитектуры и сдвиг сроков (требуется
более четкое написание ТЗ);
отсутствие должной квалификации у программиста в том языке, на
котором решено реализовывать программу.
В фазе тестирования могут возникнуть следующие риски:
риски неоконченного тестировании (программный продукт может быть
протестирован не до конца; требуется повторное тестирование).
В фазе внедрения могут возникнуть следующие риски:
риски неправильного принятия решения о законченности части проекта
(проблема незаконченности решения и возможность возникновения
нестыковок с другими частями разрабатываемой ИС; устраняется путем
доработки при следующей итерации) [26. стр.201].
2.1.3 Организационно-правовые и программно-аппаратные
средства обеспечения информационной безопасности и защиты
информации
Для выбранного комплекса задач существует несколько реализаций
информационной безопасности:
защита от внутренних угроз (разграничение прав пользователей ИС);
защита от внешних угроз;
в организации используются все возможные методы защиты
информации, так как нет уникального одного метода, который смог бы
обеспечить полную информационную безопасность, а сочетание всех
методов позволяет реализовать максимальную информационную
безопасность.
41
2.2 Информационное обеспечение задачи
2.2.1 Информационная модель и её описание
Разработаем информационную модель проектируемой информационной
системы. Информационная модель представляет собой схему, которая отражает
преобразование информационных реквизитов от источников информации до ее
получателей (другими словами, процесс обработки информации в
информационной системе). Общий вид модели представлен на рис. 2.3.
Рис. 2.3 Информационная модель ИС
Анализ построенной информационной модели позволил выделить ряд
областей, которые формализуют функционирование информационной системы.
Формально разработанную модель можно представить в виде четырех
взаимно не пересекающихся областей, соответствующих этапам
функционирования системы.
Область 1 отображает процесс ввода исходных данных и управляющих
42
воздействий на систему, которые осуществляет сотрудник сервиса. Область 2
отображает то, что из базы в рамках моделируемой задачи используются
различные справочники и данные. Область 3 отображает то, что каждый из
справочников, формируется из таблицы. Область 4 отображает то, что
моделируемая система предоставляет на выходе: сотрудник имеет возможность
формирования отчетов.
2.2.2 Характеристика нормативно-справочной, входной и
оперативной информации
Классификатор – это систематизированный список наименований
объектов, каждому из которых поставлен в соответствие уникальный код.
В системе используются системные (действующие в пределах конкретной
организации) классификаторы. Для решения задачи используются следующие
коды и классификаторы (табл. 2.1, 2.2, 2.3).
Таблица 2.1
Коды и классификаторы
Наимено-
вание кода
Идентифи-
катор
Система
кодирова-
ния
Метод
классификации
Количество
объектов
Код
категории
Код
категории
Порядковая
Последовательный
Неограниченно
Код
прейскуран
та
Код
прейскуран-
та
Порядковая
Последовательный
Неограниченно
Код
клиента
Код клиента
Порядковая
Последовательный
Неограниченно
Код
операции
Код
операции
Порядковая
Последовательный
Неограниченно
Таблица 2.2
Код категории – простой код, порядковая система кодирования.
Классификатор категорий
Наименование категории
Код категории
Продукция
1
Услуга
2
43
Таблица 2.3
Код прейскуранта – простой код, порядковая система кодирования.
Классификатор прейскуранта
Наименование продукции/услуги
Код прейскуранта
Продукция-1
1
Продукция-2
2
Услуга-1
3
Вся поступающая в информационную подсистему информация может
быть подразделена на следующие виды: условно-постоянная и условно-
переменная (табл. 2.4).
Таблица 2.4
Код клиента – простой код, порядковая система кодирования.
Классификатор клиентов
Наименование клиента
Код клиента
Иванов И.И.
1
ЗАО «Факел»
2
Смирнов П.С.
3
Власова О.А.
4
ООО «Ракета»
5
К условно-постоянной информации относятся сведения, практически
неизменные в течение длительного периода (в течение бесконечно большого
числа циклов управления). Условно-постоянная информация вводится в базу
данных достаточно редко. В проектируемой ИС «Продажи» к условно
постоянной информации относятся справочники (табл.2.5).
Таблица 2.5
Справочники
№ п/п
Наименование
Обозначение
1
Справочник категорий
Таблица «Категории»
(CATEGORY)
Данные справочников вносятся в систему при ее первичном запуске.
Кроме справочников имеются данные оперативного учета:
44
Прейскурант: код прейскуранта, название продукции/услуги, цена за ед.;
Клиенты: код клиента, название клиента, телефон, контактное лицо;
Продажи: код операции, код клиента, код продукции/услуги, количество,
дата продажи, номер договора.
Данные прейскуранта вносятся в систему по необходимости (как правило,
формируется на 1 год), общее количество – неограниченно.
Данные о клиентах вносятся в систему по необходимости, общее
количество – неограниченно.
Ввод данных в систему выполняется посредством соответствующих
экранных форм, каждая из которых содержит область данных, кнопки перехода
по данным, кнопки обработки данных и управляющие кнопки.
2.2.3 Характеристика результатной информации
Выходные данные системы формируются в виде электронных или
бумажных документов. Перечень выходных данных АРМ приведен в табл. 2.6.
Таблица 2.6
Выходные документы
Наименование отчета
Периодичность
получения
Получатель
Список клиентов
По необходимости
Менеджер по продажам
Список продаж
По необходимости
Менеджер по продажам
Характеристика и описание выходных документов представлены в табл.
27, 2.8.
Таблица 2.7
Отчет «Список клиентов»
Идентификатор
Отчет «Список клиентов»
Форма представления
Электронный документ
45
Продолжение табл. 2.7
Идентификатор
Отчет «Список клиентов»
Периодичность и сроки выдачи
По мере необходимости
Получатели и назначение
Менеджер по продажам
Источник данных (таблицы)
Клиенты
Перечень реквизитов
Название клиента, телефон, контактное лицо
Таблица 2.8
Отчет «Список продаж»
Идентификатор
Отчет «Список продаж»
Форма представления
Электронный документ
Периодичность и сроки
выдачи
По мере необходимости
Получатели и назначение
Менеджер по продажам
Источник данных (таблицы)
Продажи
Перечень реквизитов
Код клиента, код продукции/услуги, количество,
дата продажи, номер договора
2.3 Программное обеспечение задачи
2.3.1 Общие положения (дерево функций и сценарий диалога)
Для автоматизации разрабатываемого ПО существуют функции
управления, а также обработки данных. При этом можно выделить два
подмножества функций: служебные функции (например, проверки пароля,
архивации баз данных и др.) и основные функции (ввода первичной
информации, обработки, ведения справочников, ответов на запросы и др.) [10.
стр.57].
На рис. 2.4 приведена схема иерархии функций обработки данных.
46
Рис. 2.4 Иерархия функций управления и обработки данных
Для разработки структуры сценария диалога кроме выявления состава
функций и их иерархии необходимо выбрать язык общения. Меню как тип
диалога с пользователем очень удобно для пользователя системы. Реализация
диалога типа «меню» возможна через вывод на экран определенных функций
системы.
Выбор конкретной функции пользователем может осуществляться путем
выбора соответствующего пункта меню с помощью манипулятора «мышь».
Дерево функций представлено на рис. 2.5.
Рассматриваемое приложение реализует следующие режимы работы:
режим «Справочники»;
режим «Оперативный учет»;