Разработка ЭИС управления проектами для ЗАО «ДИАКОН» (1089450), страница 11

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 11)

Рисунок 3.13 — Форма отклонений

Рисунок 3.15 — Форма персонала

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

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

На Рисунке 3.17 представлен приказ о создании проектной команды. Данный приказ содержит информацию о персонале, работающим над конкретным проектом: фамилию сотрудника, его должность и ставку.

Помимо печатных форм, система также формирует ряд отчетов.

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

На Рисунке 3.18 представлен отчет о текущем состояни проекта. В нем представлены стадии проекта с их статусов, плановые и фактические даты начала и окончания каждой из стадий, а также затраты на каждую из них.

Рисунки 3.19-3.20 представляют собой отчеты о сроках, о затратах, об отклонениях и о проектах компании.

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

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

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

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

Рисунок 3.16 — План-график проекта

Рисунок 3.17 — Приказ о создании проектной команды

Рисунок 3.18 — Отчет о текущем состоянии проекта

Рисунок 3.19 — Отчет о сроках

Рисунок 3.20 — Отчет о затратах

Рисунок 3.21 — Отклонения проекта

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

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

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

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

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

Рисунок 3.22 — Отчет о проектах компании

3.5 Технология тестирования ЭИС

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

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

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

Основные виды тестирования:

• блочное — тестирование полного класса, метода или небольшого приложения, написанного одним программистом или группой, выполняемое отдельно от прочих частей системы;

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

• интеграционное — это совместное выполнение двух или более классов, пакетов, компонентов или подсистем, созданных несколькими программистами или группами;

• регрессивное — повторное выполнение тестов, направленное на обнаружение дефектов в программе, уже прошедшей этот набор тестов;

• тестирование системы — выполнение ПО в его окончательной конфигурации, интегрированного с другими программными и аппаратными средствами.

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

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

3.5.1 Выбор методики тестирования программной системы

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

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

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

К недостаткам данного метода можно отнести:

• количество независимых маршрутов может быть очень велико;

• исчерпывающее тестирование маршрутов не гарантирует соответствия программы исходным требованиям к ней;

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

Достоинства метода связаны с тем, что принцип белого ящика позволяет учесть особенности программных ошибок:

• количество ошибок минимально в «центре» и на «периферии» программы;

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

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

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

Таким образом, основное место приложения тестов черного ящика — интерфейс ПО. Эти тесты демонстрируют:

• как выполняются функции программы;

• как принимаются исходные данные;

• как вырабатываются результаты;

• а также как сохраняется целостность внешней информации.

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

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

• некорректные или отсутствующие функции;

• ошибки интерфейса;

• ошибки во внешних структурах данных или в доступе к внешней базе данных;

• ошибки характеристик (например, необходимая емкость памяти);

• ошибки инициализации и завершения.

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

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

3.5.2 Технология обеспечения информационно безопасности ЭИС

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

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

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

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

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

Характеристики

Список файлов ВКР