Аналитическая часть (стр. 3 )

§  тестирование и развитие проекта, осуществляемые одновременно с разработкой,

§  ведение разработки немногочисленной, хорошо управляемой командой профессионалов,

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

Подход RAD применим для относительно небольших проектов, разрабатываемых для конкретного заказчика, для построения несложных систем, содержащих небольшой объем уникального кода (до тысячи операторов), что соответствует требованиям к дипломному проекту.

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

Цель данного проекта – разработать ИС, удовлетворяющую необходимым требованиям, изложенным в главе I. Эти требования составляют ограничения по качеству.

Состав задач проекта автоматизации обусловлен спецификой принятого стандарта построения схемы ЖЦ проекта. Комплексный план-график (см. рисунок 4) отражает сущность проекта автоматизации до окончания этапа разработки с точки зрения состава работ и распределения их во времени.

Разработка и анализ сетевого плана-графика были произведены в среде приложения Microsoft Project Professional 2009. Это приложение позволяет реализовать принципы метода сетевого планирования и управления.

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

Следующим этапом разработки ИС является написание технического задания (ТЗ), в котором отображены требования к программному продукту.

На основе анализа и требований начинается проектирование ИС, которая будет представлять собой программный продукт, работающий посредством БД.

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

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

Рисунок 4. Диаграмма Гантта проекта автоматизации задачи

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

Существует четыре способа внедрения новой системы:

1.  Параллельная стратегия.

2.  «Скачок».

3.  Пилотный проект.

4.  «Узкое место».

Специфика работы предприятия ООО “Мобимарк” предполагает невозможность приостановки работы предприятия из-за внедрения новой ИС, поскольку это может повлечь за собой потерю клиентской аудитории, ошибки в выполнении документооброта и, как следствие, упущенную прибыль. Также риск влияния неудачного внедрения на эффективность работы предприятия должен быть минимальным или отсутствовать.

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

Метод «узкого места» является принципиально неприемлемым для разрабатываемого проекта, так как предполагает внедрение ИС в наиболее критический участок работы предприятия, с тем, чтобы в дальнейшем перейти к полномасштабному внедрению на всем предприятии. Решаемая задача изначально решается на одном участке, переход на уровень всего предприятия в целом не запланирован.

Таким образом, наиболее приемлемыми представляются два варианта технологии внедрения ИС – параллельная стратегия и стратегия пилотного проекта. Их сравнительная характеристика приведена в таблице 6.

Таблица 6.

Сравнительная характеристика стратегий внедрения ИС.

Позиция	Параллельная стратегия	Пилотный проект
Случай применения	Старую рабо- тающую систему необходимо заменить новой	Тактика «скачка», но применяемая к ограниченному числу функций.
Область применения	Не имеет значения	Малый участок деятельности
Риск срыва работы предприятия	Риск минимальный	Стратегия нацелена на снижение риска при внедрении
Дублирование операций	Есть	Нет

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

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

Рисунок 5. Диаграмма Гантта этапа внедрнеия ИС.

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

В результате выполнения этапа внедрения составляется «Акт готовности объекта к эксплуатации», формируется состав приемной комиссии, издается «Приказ о начале эксплуатации». Это означает, что в течение достаточного длительного времени обе системы, новая и старая, работали одновременно, результаты их работы совпадали, количество ошибок новой системы сведено к минимуму.

На стадии эксплуатации и сопровождения выполняются следующие этапы:

1.  Эксплуатация проекта.

2.  Сопровождение и модернизация проекта.

На этой стадии решается вопрос о том, чьими силами будут осуществляться эксплуатация и сопровождение проекта. При решении поставленной задачи автоматизации разработка проекта производится собственными силами, без привлечения специалистов со стороны. Поэтому сопровождение проекта и его эксплуатация будут осуществляться внутренними силами, то есть теми специалистами-разработчиками проекта, а также персоналом IT-cлужбы.

В процессе выполнения этапа «Эксплуатация проекта» осуществляются следующие работы:

§  исправления в работе всех частей системы при возникновении сбоев,

§  регистрация этих случаев в журналах,

§  отслеживание технико-экономических характеристик работы системы,

§  накопление статистики о качестве работы всех компонентов системы.

На этапе «Сопровождение и модернизация проекта» выполняются следующие работы:

§  анализ собранного статистического материала,

§  анализ соответствия параметров работы системы требованиям окружающей среды.

Анализ осуществляется создаваемой для этих целей комиссией.

Результаты анализа позволяют:

§  сделать заключение о необходимости модернизации всего проекта или отдельных его компонентов,

§  определить объемы доработок, сроки и стоимость выполнения этих с целью получения «Техно-рабочего проекта», прошедшего модернизацию.

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

2.1.2 Ожидаемые риски на этапах жизненного цикла и их описание

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

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

1) болезни и увольнение сотрудни-
ков

2) Изменение графика ра-
бот

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

Технические риски - связаны с проблемами реализации техничес-
ких решений. К техническим рисками в нашем случае будут относится:

1) пробле-
мы разработки, то есть способность разработчиков реализовать ту или иную
задачу,

2) неудовлетворительная производительность системы,

3) внедре-
ние и затруднения, связанные с окончательной адаптацией системы под
конечных пользователей.

Ответственное лицо за решение подобных проблем — обычно тех-
нический руководитель проекта.

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

2.2. Информационное обеспечение задачи

2.2.1 Информационная модель и её описание

Информационная модель задачи автоматизации ведения заказов клиентов представляет собой схему, отражающую преобразование информационных реквизитов от источников информации до её получателей. Модель построена в соответствии с описанием схемы данных из ГОСТ (см. рисунок 6). Модель имеет шести логических уровней:

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

·  Первичные документы или файлы. К ним относятся: данные введенные менеджерами, так же устная информация от клиентов

·  Таблицы с первичными документами. К ним относится таблица «Файлы», где хранится информация о параметрах файлов сотрудников. Также это таблица «Форум», где содержится полная информация об имеющихся в наличии документах.

·  Таблицы с промежуточной информацией. Это справочники БД, которые необходимы для заполнения экранных форм или для составления и вывода на экран и печать отчетов по задаче. К ним относятся: справочники «Шаблоны», «Пользователи», «Группы», «Подписка».

·  Результатные документы или файлы. Это файлы БД, полученные путем выборки по запросам из БД. К ним относятся: «Результат поиска», «E-mail рассылка.

·  Получатели информации: сотрудник, получающий файл, нотификацию на подписанные документы.

Рисунок 6. Информационная модель ИС задачи автоматизации

2.2.2. Используемые классификаторы и системы кодирования

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

К объектам классификации и кодирования относятся:

§  справочные реквизиты-признаки, описывающие процессы, место, время выполнения процессов, субъекты и объекты действия, отражаемые в показателе,

§  наименования показателей и документов, наименования компонентов проекта ИС (файлов, задач, подсистем, программных модулей, и прочее).

Целью разработки классификатора является установление соответствия между значениями справочных или описательных признаков какого-либо элемента или процесса и значениями группировочных признаков (закодированных аналогов справочных признаков). Для кодирования объектов необходимо их упорядочить по некоторым признакам.

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

§  наличие в системе неограниченного количества признаков классификации,

§  соподчиненность признаков классификации,

§  логичность построения, простота и удобство обработки (преимущество),

§  жесткая структура классификации (недостаток).

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

Код – условное обозначение в виде знака или группы знаков в соответствии с принятой системой.

Известны следующие системы кодирования:

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

2.  Порядковая – наиболее простая по своему построению, использующая последовательное присвоение каждому объекту классификации номера его порядка.

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

По сфере действия классификаторы делят на:

§  международные – обязательные для передачи информации между организациями разных стран мирового сообщества,

§  общегосударственные (общесистемные) – принятые для передачи информации между предприятиями различных отраслей народного хозяйства в пределах отдельного государства,

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

§  локальные – принятые в пределах отдельного предприятия, предназначенные исключительно для внутреннего использования.

Состав кодовых обозначений объектов оформлен в таблице 7.

Таблица 7.

Состав кодовых обозначений объектов классификации

наименование кодируемого множества объектов	длина кода, знаки	система кодирования	система классификации	вид классифика-тора
Пользователи	10	Регистрационная	иерархическая	локальный
Группы	10	Регистрационная	иерархическая	локальный
Шаблон	10	Регистрационная	иерархическая	локальный
Подписка	10	Регистрационная	иерархическая	локальный

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

“Группы“ необходим для составления групп разграничения доступа.

“Шаблон“ содержит шаблоны для документов набираемых вручную.

“Подписка” содержит пользователей подписанных под

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

В проекте применяется система кодирования. Права доступа к объекту кодируется тремя буквами латинского алфавита (см. таблицу 8)

Таблица 8

Расшифровка буквенных прав доступа

Буква	Расшифровка
r	Разрешается чтение документа
w	Разрешается изменение документа и добавление комментариев
-	Запрещение действий над документом

Пример прав доступа

“rw” – разрешено чтение и запись

“r” – разрешено только чтение

2.2.3 Характеристика нормативно-справочной, входной и оперативной информации

К формированию входных данных так же относится форма поиска (рисунок 7)

Рисунок 7. Макет формы Поиска

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

Для ввода прав доступа к документам используется форма Права (рисунок 8 )

Рисунок 8. Макет формы Права

Рабочая зона разделена на 2 части.

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

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

Для создание более универсальных договоров используется форма Создание шаблона (рисунок 9)

Рисунок 9. Макет формы Создание шаблона

На форме находится многостраничное поле ввода для введение HMTL кода и кнопки Применить и Отмена.

Для создание договора на утверждение используется форма “Создание задачи и документа” (рисунок 10)

Рисунок 10. Макет формы Создание задачи и документа

На форме расположено выбор Шаблона, данные берутся из справочника Шаблоны, название шаблона и раздел в котором создаётся задача. При выборе шаблона, он подряжается в серую область на форме.

Для подписание на рассылки необходима форма Подпись на рассылки (рисунок 11)

Рисунок 11. Макет формы Подпись на рассылки

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

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

Таблица 9

Параметры справочников

Название справочника	Ответственный за ведение	Средний объём справочника в записях	Средняя частота актуализации ( раз в год )	Средний объем актуализации в %
Шаблоны	Администратор	5	5	90
Рассылки	Менеджер	50	50	50
Пользователи	Администратор	10	10	80
Группы	Администратор	3	3	90

Реквизитный состав справочников следующий:

Справочник шаблоны имеет поле уникального номера, поле для ввода кода шаблонна договора.

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

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

Справочник Группы имеет поле уникального номера, номер участника и номер его одногруппника.

2.2.4 Характеристика результатной информации

Основными таблица сохраняющими результат ИС являются таблицы

Форумы и Файлы.

Таблица Форумы имеет следующие реквизиты

1) № Записи – номер уникальной записи в форуме

2) № сообщения – номер сообщения-комментария из таблицы Сообщения

3) Проверен – указывает на статус проверки

4) Согласован - указывает на статус согласования

5) Закрыто - указывает на статус закрытия документа, что запрещает его дальнейшее обсуждении

6) № файла – номер файл из таблицы Файлы

7) № пользователя – номер пользователя создавшего запись из таблицы

8) Права родителя – права создателя

9) Права группы – права группы

10) Права остальных – права всех остальных участников.

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

Макет экранной формы «Результат поиска» приведен на рисунке 12.

Рисунок 12. Макет экранной формы «Заявка»

На форме предоставлено поле, где мы вводили требуемый запрос, кнопка поиска и результативная искомая информация представленная в виде таблице с столбцами: №, ФИО, Комментарий. Данные формы создаются на основе таблицы форумы.

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

1) Лицо в виде исполнителя

2) Лицо в виде заказчика

3) Перечень услуг

4) Права и обязанности сторон

Главной формой является форма утверждения договора ( рисунок 13)

Рисунок 13. Макет экранной формы «Утверждение договора»

Форма имеет следующие реквизиты:

1) Название договора

2) Комментарий договора

3) Комментарии пользователей

4) Права участников

5) Текст для добавление комментария.

2.2.5. Формализация расчётов показателей в подзадачах автоматизации

Специфика проведения расчетов параметров заказа по данной задаче автоматизации отражена в таблицах 10 и 11.

Таблица 10.

Формализованное описание входных показателей

№ п/п	Наименование входного показателя	Идентификатор входного показателя
1	Стоимость акции	Si
2	Количество заказов	n
3	Cкидка	С
4	Стоимость одной СМС	Рj
5	Количество смс	d
6	Агентская ставка	t

Таблица 11.