Система дает возможность предварительного запроса на аудиторскую услугу

В систему внесены документы гарантирующие выполнение заказов

Стоит отметить, что на ресурсе представлена вся интересующая информация для клиента.

Вывод из обзора аналогов существующих веб систем для аудиторских фирм

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

Но так как все системы очень специфичны и созданы именно для той фирмы в которой в последующем будут работать. Факторы (расчет стоимости услуг фирмы, предоставляемые услуги, консультации и др.) для каждой фирмы разные и поэтому будет создана современная система, отвечающая требованиям по предоставлению услуг для аудиторской фирмы ООО АНИТ - Аудиторские услуги.

1.3 Техническое задание

Общие сведения

Полное наименование системы и ее условное обозначение

Полное наименование Системы: Инфотмационная система ООО «АНИТ - Аудиторские услуги». Подсистема управления взаимоотношениями с клиентами.

Сведения о заказчиках и исполнителях

Заказчик: фирма ООО «АНИТ - Аудиторские услуги» города Владимира.

Форма собственности: ООО

Исполнитель: Русин Дмитрий Вадимович

Основание разработки

Основанием для разработки ИС является учебный план специальности 230201 в рамках курсовой работы по дисциплине «Проектирование ИС».

Настоящее ТЗ разработано в соответствии с требованиями ГОСТ 34.602_89 «Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы».

При создании проектно-эксплуатационной документации Исполнитель должен руководствоваться требованиями следующих нормативных документов Госстандарта:

1) ГОСТ 34. Информационная технология. Комплекс стандартов на автоматизированные системы;

2) РД 50-34.698-90. Методические указания. Информационная технология. Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов;

3) ГОСТ 19. Единая система программной документации(ЕСПД).

Сроки исполнения работ

Плановые сроки начала и окончания работы:

Работы по созданию ИС сдаются и принимаются поэтапно в соответствии с календарным планом работ, разработанным исполнителем и утвержденным заказчиком.

Начало разработки - 01.07.2012 г.

Окончание разработки - 07.12.2012 г.

Сведения об источнике и порядке финансирования работ

Финансирование ведется за счет собственных средств Исполнителя.

Назначение и цели создания системы

Назначение системы

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

Общие цели создания системы

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

Исходными данными для проведения работ является:

- Информация о деятельности фирмы;

- Отсутствие системы у фирмы.

Характеристика объектов автоматизации

Краткие сведения об объектах автоматизации

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

Сведения об условиях эксплуатации

Информационные процессы, возникающие при эксплуатации ИС, протекают непрерывно в течение всего рабочего времени субъектов.

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

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

Требования к информационной системе

Функции системы

- возможность заказать аудиторские услуги;

- возможность обработать и проанализировать заказы;

- возможность сопоставлять похожие заказы;

- показ актуальной информации о фирме и чем она занимается.

Требования к системе в целом

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

Общими требованиями к Системе являются:

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

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

- Предоставляемая информация должна иметь очевидную ценность для пользователей Системы.

Требования к структуре и функционированию системы

Требования к способам и средствам связи для информационного обмена между компонентами системы

Для обеспечения информационного обмена, компоненты Системы должны работать в составе единой вычислительной сети, построенной по технологии Интернет/интранет.

В качестве базового протокола сетевого и межсетевого взаимодействия должен использоваться TCP/IP (сокращение от английского Transfer Control Protocol / Internet Protocol, протокол управления передачей/протокол-Интернет) - стек протоколов Интернет.

Требования к приспособляемости (к изменению условий эксплуатации), масштабируемости системы

В случае изменения условий эксплуатации системы, должны выполняться следующие требования:

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

- в процессе адаптации защищенность не должна становиться хуже существующей на момент начала адаптации.

Требования к надежности

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

В целях обеспечения надежного функционирования система должна обеспечивать:

а) сохранение целостности данных при нештатном завершении программы в случае отказа рабочей станции;

б) сохранение работоспособности программного обеспечения при некорректных действиях пользователя;

в) резервное копирования баз данных.

Вероятность безотказной работы системы за 500 часов должна быть не менее 0,99.

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

Надежность в части технического обеспечения должна обеспечиваться:

- защитой технических средств по электропитанию путем использования источников бесперебойного питания;

- дублированием носителей информационных массивов.

Требования безопасности

Система должна соответствовать требованиям российского законодательства по информационной безопасности для органов власти и управления. Требования безопасности разрабатываются на стадии проектирования системы.

Требования по эргономике и технической эстетике

Дизайн Системы должен удовлетворять следующим требованиям по эргономике и технической эстетике:

- быть достаточно «легким» по объему графических элементов и обеспечивать как можно большую скорость загрузки страниц портала;

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

- обеспечивать минимум усилий и временных затрат пользователя для навигации по страницам портала;

- обладать развитой системой поиска информации;

- корректно отображаться при всех возможных разрешениях и количестве одновременно отображаемых цветов монитора;

- сохранять идентичность отображения на большинстве современных ОС и web-браузерах;

- обладать системой подсказок в местах, где у пользователя потенциально могут возникнуть затруднения;

- обеспечивать обратную связь с пользователем в полном объеме посредством web-браузера с применениями почтовых клиентов или иных программ;

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

- предусматривать возможность поддержки мультиязычного контента;

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

Требования к эксплуатации, техническому обслуживанию, ремонту и хранению.

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

1) Взаимодействие вычислительных средств со скоростью обмена данными между конечными узлами сети не менее 100 Мбит / сек и скоростью обмена с центральной площадкой сети Интернет не ниже 10 Мбит / сек по каждому из каналов связи (основному и резервным);

2) Электропитание технических средств от сети напряжением 380 / 220В с частотой 50 Гц с глухо-заземленной нейтралью. По основным показателям качества электроэнергии системы первичного электропитания должны соответствовать требованиям ГОСТ 13109-87, а по электромагнитной совместимости и устойчивости к электромагнитным помехам - ГОСТ Р50628-93 и МЭК-555-2;

3) Физическая защита аппаратных компонентов системы, носителей данных, резервирование ресурсов и текущее обслуживание реализуется техническими и организационными средствами, предусмотренными в структуре площадки, предоставленной Заказчиком;

4) Техническое обслуживание, ремонт и хранение компонентов системы осуществляется штатными специалистами, предусмотренными в структуре площадки, предоставляемой Заказчиком.

Требования к обеспечению информационной безопасности

Требования к обеспечению информационной безопасности, можно разбить на несколько составляющих:

- Общие требования

- Требования к структуре и функциям СЗИ (Система защиты информации)

- Требования к программному и аппаратному обеспечению

Общие требования

Общие требования к Системе включают:

- специализированная информационная система не обрабатывает конфиденциальную информацию;

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

- развернутые и уточненные требования к структуре, функциям и средствам СЗИ должны быть разработаны на этапе технического проектирования ИС;

- СЗИ должна обеспечивать необходимую и достаточную защиту ресурсов ИС от характерных угроз безопасности, определенных с учетом объективных факторов и анализа возможных моделей нарушителей;

- СЗИ должна предполагать независимость функционирования каждой из входящих в ее состав структурных подсистем защиты. Нарушение функционирования любой подсистемы защиты не должно приводить к нарушению функционирования других подсистем защиты;

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

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

Разделение прав доступа

Разделение прав доступа предусматривается.

Общие требования к информации

Информация, представленная в ИС должна соответствовать следующим требованиям:

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

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

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

- Историческая преемственность материалов. Сохранение ранее опубликованных материалов, чтобы можно было отследить историю проблемы.

Требования по сохранности информации.

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

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

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

Режим работы круглосуточный

Вероятность безотказной работы системы за 500 часов должна быть не менее 0,99

Достоверность выдаваемой информации 0,995

Требования к достоверности официально публикуемой информации

К официально публикуемой информации предъявляются следующие требования:

- Информационные материалы, размещаемые в Подсистеме, должны быть своевременны, точны, и отражать текущее (действительное) состояние;

- Формы интерактивных сетевых сервисов должны быть просты и понятны. Документы, сопутствующие интерактивным процедурам соответствуют ведомственным формам в твердой копии;

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

- В случае выявления (обнаружения) ошибок и неточностей в материале Администрация в обязательном порядке публикует исправленный текст и дополнительно сообщает посетителям о факте исправления. Новый (исправленный) документ (материал) сопровождается обязательным комментарием.

Требования к видам обеспечения

Четыре вида обеспечения:

- Информационное обеспечение;

- Лингвинстическое обеспечение;

- Программное обеспечение системы;

- Техническое обеспечение системы.

Информационное обеспечение

Типовой формат страниц в разделах и размещение материалов на них определяются заданными при разработке Системы шаблонами.

На главной странице каждого раздела Системы должны размещаться:

- ссылки на все его разделы и подразделы;

- основные навигационные элементы;

- ссылка на главную страницу Системы.

Лингвинстическое обеспечение

Под лингвистическим обеспечением понимаются:

- язык операционной системы и серверных приложений на базе которых построена Подсистема;

- язык приложений, используемых для подготовки документов;

- кодировка подготавливаемых и хранимых документов;

- язык документов и web-приложений;

- поддерживаемые кодовые страницы опубликованных документов;

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

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

Программное обеспечение системы

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

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

Базовое ПО должно поддерживать и использовать стандартные сетевые протоколы передачи данных.

Техническое обеспечение системы

В состав комплекса технических средств должны входить:

- серверы баз данных;

- серверы приложений;

- рабочие станции;

- периферийное оборудование [4].

2. ПРОЕКТИРОВАНИЕ СИСТЕМЫ

2.1 Обоснование и выбор методологии проектирования

язык программирование сервер данные

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

Концепция UML принципиально отличается от «традиционных» технологий (в частности, от блок-схем и электронных таблиц). Вместо того чтобы иллюстрировать изолированные части процесса, UML отдает предпочтение диаграммам верхнего уровня, позволяющим разработчикам скрывать детали и концентрироваться на функциональных особенностях, а не на последовательности действий. Данный подход предоставляет возможность начать с формирования общего взгляда на приложение, детали же раскрываются позже [1].

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

В UML созданы следующие модели (каждая модель представлена соответствующим типом диаграммы):

- модель классов (Class Model). Служит для описания статической структуры системы: иерархии классов и отношений между ними;

- модель взаимодействий: объекты (Collabo-ration Model) и сценарии (Sequence Model). Служит для описания механизмов взаимодействия объектов системы, реализующих ту или иную функцию;

- модель процессов: физическая архитектура системы (Deployment Model). Описывает распределение процессов по процессорам в физическом проекте системы;

- модель программных модулей (Component Model). Описывает распределение классов и объектов системы по модулям в физическом проекте системы;

- модель действий (Activity Model). Предназначена для описания алгоритмов системы (для методов классов, нескольких классов) и является вариантом поведенческой модели без сообщений.

Каждая из диаграмм, используемых в UML, позволяет рассматривать бизнес-процессы под определенным углом [6].

2.2 Структура ИС

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

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

2.3 Разработка модели системы

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

Диаграмма прецедентов представлена на рисунке 16.

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

Оформить заказ.

1. Краткое описание

Этот прецедент описывает порядок оформления заказа.

Актер - клиент.

2. Поток событий

Основной поток: клиент оформляет заявку на аудиторскую услугу.

1) Клиент проходит авторизацию входит в систему.

2) Входит в систему.

3) Просматривает услуги.

4) Может оставить отзыв.

5) Клиент выбирает ссылку Заказ.

6) Система откликается на вызов и выводит форму заказа.

7) Заполняет данные в форме.

8) Заполняет данные на услуги.

9) Система формирует документ: Заказ на услугу.

10) Клиент может вернуться в главное меню программы.

Альтернативный поток 1: Ошибка загрузки данных

Вывести сообщение об ошибке, если произошел сбой работы базы данных, конфигурации или приложения.

а) Предусловие

Успешный отклик на запрос получения формы о заказа.

б) Постусловие

После успешной загрузки формы заказа клиент может заполнить необходимые данные.

Диаграмма классов

Диаграмма классов (class diagram) служит для представления статической структуры модели системы в терминологии классов объектно-ориентированного программирования. Диаграмма классов может отражать, в частности, различные взаимосвязи между отдельными сущностями предметной области, такими как объекты и подсистемы, а также описывать их внутреннюю структуру и типы отношений [2].

На диаграмме классов (рисунок 17) представлены:

Клиент, Счет, Заказ, СRM система, Услуга

Диаграмма видов деятельности

Диаграмма видов деятельности (рисунок 18,19) показывает последовательность этапов, образующих сложный процесс. Диаграмма деятельности сосредоточивает внимание на операциях, а не на объектах [2].

Диаграмма последовательности (рисунок 20,21).

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

Диаграмма развертывания (рисунок 22).

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

Диаграмма отражает физические взаимосвязи между программными и аппаратными компонентами [2].

Диаграмма состояния (рисунок 23).

Диаграмма состояния определять множество систем от компьютерных программ до бизнес-процессов.

2.4 Разработка сетевого плана выполнения проектных работ

2.4.1 Определение состава работ по стадиям и этапам (таблица 1)

Таблица 1 - Определение состава работ по стадиями этапам

Перечень работ, проводимых на выделенных этапах разработки ИС «АНИТ - Аудиторские услуги» соответствует ГОСТ 34.601-90, однако, учитывая выбранную методологию проектирования и специфику ИС, целесообразно внести некоторые уточнения в содержание проводимых работ:

1.1. Обследование объекта и обоснование необходимости создания ИС:

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

1.2. Формирование требований пользователя к ИС:

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

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

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

2.1 Выбор и обоснование выбранной методологии проектирования и разработки.

На данном этапе разработчик предоставляет обоснование выбранной методологии проектирования ИС «АНИТ - Аудиторские услуги» заказчику проекта.

2.2 Изучение объекта автоматизации: сбор информации о деятельности предприятия, изучение регулярного документооборота предприятия, сбор сведений об информационно-вычислительной структуре предприятия.

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

2.3. Разработка вариантов концепции ИС и выбор варианта концепции АС, удовлетворявшего требованиям пользователя:

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

2.4. Создание схем бизнес процессов в предприятии и схем документооборота.

Суть этапа в описании бизнес процессов на данный момент, включая выбранную альтернативу (концепцию) системы.

Создание схем документооборота фирмы.

3.1. Разработка и утверждение технического задания на создание ИС:

На этом этапе проводят согласование и утверждение ТЗ на проектируемую ИС.

3.2. Оформление ТЗ и его утверждение

На этом этапе идет оформление технического задания на проектируемую ИС.

4.1. Разработка предварительных проектных решений по системе и ее частям:

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

4.2. Разработка документации на АС и ее части:

Смысл этапа в составлении и согласовании, оформлении и утверждении полной документации по всем функциям подсистем и самой системы по ГОСТ 34.201.

5.1. Разработка проектных решений по системе и ее частям:

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

5.2. Разработка документации на ИС и ее части:

Смысл этапа в составлении и согласовании, оформлении и утверждении полной документации по всем функциям подсистем и самой системы по ГОСТ 34.201.

6.1. Разработка рабочей документации на систему и ее части:

Составляется рабочая документация все сведения, достаточные для проведения работ по внедрению проектируемой ИС, ее эксплуатации, поддержании качества системы в дальнейшем; оформление рабочей документации по ГОСТ 34.201.

6.2. Разработка или адаптация программ:

На этом этапе проводят выбор программных средств системы, адаптацию приобретаемого ПО и разработку программной документации в соответствии с ГОСТ 19.101.

7.1. Подготовка объекта автоматизации к вводу ИС в действие:

На этом этапе проводят подготовку проектируемой системы к введению в эксплуатацию, реализацию организационной структуры ИС и т.д.

7.2. Подготовка персонала:

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

7.3. Комплектация ИС поставляемыми изделиями (программными и техническими средствами, программно-техническими комплексами, информационными изделиями):

На данном этапе получаем комплектующие проектируемой ИС (аппаратные средства и ПО), осуществляется контроль качества изделий.

7.4. Пусконаладочные работы:

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

7.5. Проведение предварительных испытаний:

На этом этапе проводятся испытания всей системы на работоспособность и соответствие ТЗ, устранение неполадок и изменение ряда документаций.

7.6. Проведение опытной эксплуатации:

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

7.7. Проведение приемочных испытаний:

Этап заключается в испытаниях на соответствие ТЗ относительно программы и методики приемочных испытаний; анализируются испытания системы и устраняют неполадки; оформляется акт о приемке системы в постоянную эксплуатацию.

8.1. Выполнение работ в соответствии с гарантийными обязательствами:

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

8.2. Послегарантийное обслуживание:

Этап заключается в следующем:

- анализ функционирования системы и сравнение ее заявленных характеристик, с фактическими;

- если существуют отклонения, устанавливается их причина;

- устраняются недостатки АС с внесением изменений в документацию [5].

2.4.2 Построение первоначального исходного сетевого плана

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

На рисунке 24 представлен первоначальный сетевой план.

1 - получение заказа от заказчика на разработку ИС;

2 - получение отчета о результатах обследования объекта и сформированных требований пользователя к ИС;

3 - получение отчета с обоснованием выбора концепции ИС;

4 - получение отчета с эскизом будущей системы

5 - получение отчета с окончательным вариантом концепции ИС

6 - Получение отчета с разработанными диаграммами, соответствующими функционально-ориентированной методологии

7 - Получение оформленной документации

8 - Получение отчетов о результатах внедрения

9 - выполненные гарантийные обязательства.

1-2 - формирование требований к ИС (10 рабочих дней);

2-3 - Разработка технического задания (5 рабочих дней);

3-4 - Формирование эскизного проекта (10 рабочих дней);

4-5 - Составление технической документации (16 рабочих дней);

5-6 - Составление рабочего проекта (15 рабочих дней);

6-7 - Ввод системы в действие (10 рабочих дней);

7-8 - Сопровождение (25 рабочих дней);

Таким образом Tкр=106 дней Tдир = 86. Таким образом Tкр > Тдир

2.4.3 Закрепление исполнителей за работами

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

Таблица 2 - Закрепление исполнителей за работами

2.4.4 Корректировка исходного сетевого плана

В соответствии с «ГОСТ 34.601 - 90» стадию «Технический проект» и «Тестирование» объединим в стадию «Технорабочий проект». Оптимизированный сетевой план представлен на рисунке 25.

Условные обозначения событий:

0) заказ на разработку

1) формирование требований

2) разработка концепции

3) техническое задание

4) технорабочий проект (технический проект, тестирование)

5) ввод в эксплуатацию, документирование

6) сопровождение

0-1 формирование конкретных требований заказчика к проекту для начала более детального изучения объекта автоматизации (7 дней);

1-2 соответствии с выполненными работами на стадии описания и обоснования предлагаемого варианта концепции методического комплекса проводят разработку технического задания на ИС (5 дней);

2-3 разработка предварительных проектных решений по методическому комплексу, а также разработка документации на систему(7 дней);

3-4 соответствии с эскизным проектом осуществляется разработка проектных решений по системе, проводится подготовка документации на поставку изделий для комплектования ИС (40 дней);

4-5 - Подготовка объекта автоматизации к вводу ИС в действие. Тестирование и устранение недостатков(7 дней);

5-6 - Осуществление внедрения проекта в эксплуатацию, документирование (10 дней).

За счет объединения 2-х стадий время выполнения проекта уменьшилось на 5 дней. Таким образом, общее время создания проекта (критический путь) уменьшится до 76 дней. В результате этого окончательная стоимость проекта будет снижена (рисунок 26).

1 - Диаграмма прецедентов

2 - Диаграмма классов

3 - Диаграмма состояний

4 - Диаграмма видов деятельности

5 - Программирование модулей

6 - Тестирование функций

7 - Конфигурирование и дизайн

8 - Окончательное оформление рабочей документации

1-2,- Разработка диаграммы состояний; Длительность данного процесса 2 рабочих дня.

2-3,- Разработка диаграммы видов деятельности; Длительность данного процесса 2 рабочих дня.

4-5 Разработка диаграмм состояния за 2 дня

2-5,- Описание диаграмм. Разработка диаграммы развёртывания; описание нестандартных модулей; Длительность данного процесса 5 рабочих дней.

5-6,- Тестирование проекта. Длительность данного процесса составляет 7 рабочих дней;

5-7,- Создание конфигурации проекта и его оформление. Длительность данного процесса составляет 3 рабочих дня;

6,7-8,- Окончательное оформление рабочей документации. Длительность данного процесса составляет 4 рабочих дня;

Таким образом, оптимизированный график выглядит так, как на рисунке 27.

1-2 - формирование требований к ИС

2-3 Разработка Технического задания

3-4 - составление технорабочего проекта

4-5 - ввод системы в действие

5-6 - сопровождение системы

оптимизированное Ткр = 84, что меньше Тдир

2.4.5 Разработка плана контрольных мероприятий при проектных работах

Необходимо каждому участнику проекта выделить сроки по выполнению задач. Это оформляется в виде календарного плана контрольных мероприятий (таблица 3).

Таблица 3 - План контрольных мероприятий

2.5 Оценка надежности системы

2.5.1 Оценка надежности

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

Схема последовательного соединения элементов представлена на рисунке 28.

Значения интенсивности отказов элементов проектируемой системы представлены в таблице 4.

Таблица 4 - Интенсивность отказов узлов системы

Схема проектируемой системы представлена на рисунке 29.

Расчет надежности необходимо производить при следующих заданных условиях:

1) Заданная наработка часов.

2) Заданное значение вероятности безотказной работы .

3) Заданное значение достоверности выдаваемой информации .

Рассмотрим основное соединение элементов

Рассчитаем основные характеристики надежности:

- интенсивность отказа;

- вероятность исправной работы;

- вероятность отказа;

- частота отказа;

- среднее время безотказной работы;

- среднее время безотказной работы при заданной наработке t=500

Вывод:

,

Таким образом, для повышения значения показателя надежности системы воспользуемся введением резервированием.

Общее резервирование (ненагруженный режим)

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

Схема общего резервирования представлена на рисунке 30.

Таким образом, . Данная схема резервирования неэффективна.

Общее резервирование (нагруженный режим)

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

Рассчитаем основные характеристики надежности:

2

Таким образом, мы снова не достигли заданного уровня надежности

Поэлементное резервирование (ненагруженный режим)

Обеспечим отдельное резервирование элементов в ненагруженном режиме.

Поэлементное резервирование представлено на рисунке 31.

Рассчитаем основные характеристики надежности:

Поэлементное резервирование (нагруженный режим)

Рассчитаем основные характеристики надежности в нагруженном режиме:

Вывод:

,

.- достигнуто требуемое значение показателя надежности.

Но данная схема резервирования экономически не целесообразна. Из выбранных нами основных элементов наибольшую важность представляют такие ресурсы, как процессор и память. Рассчитаем характеристики надежности при поэлементном резервировании именно этих элементов и сравним их значения с требуемыми.

Поэлементное резервирование (нагруженный режим (рисунок 32))

Рассчитаем характеристики надежности для поэлементного резервирования наиболее важных элементов в нагруженном режиме.

Поэлементное резервирование (ненагруженный режим)