Разработка электронного сайта по предмету "Математические методы"

Размещено на http://www.allbest.ru/

Оглавление

Введение

Глава 1. Юридическая часть

1.1 Особенности договора оказания услуг

1.2 Составление договора на оказание услуг по проектированию программного обеспечения

1.3 Форс-мажорные обстоятельства договора

Глава 2. Экономический расчет программного обеспечения сайта «математические методы»

2.1 Расчёт периода изготовления программного продукта

2.2 Расчёт стоимости программного продукта

2.3 Расчет себестоимости программного продукта

Глава 3. Проектная часть

3.1 Алгоритм создания программного продукта

3.2 Структура создания программного продукта

3.3 Конструктивная часть создания программного продукта

Глава 4. Тестирование програного продукта

4.1 Метод белого ящика

4.2 Метод черного ящика

4.3 Тестирование программного продукта разными браузерами

Заключение

Список литературы

Приложения

Введение

Вторая половина ХХ века стала периодом перехода к информационным обществам. Лавинообразный рост объёмов информации принял характер информационного взрыва во всех сферах человеческой деятельности.

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

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

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

Актуальность

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

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

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

Целью дипломного проектирования является разработка программного обеспечения - учебного пособия в виде сайта на тему «Земельно-имущественные отношения».

Задачами дипломного проектирования является:

1. Разработка программного обеспечения - учебного пособия в виде материалов на сайте : лекции, экзаменационные вопросы по предмету «Математические методы»;

2. Разработка интерфейса сайта «Математические методы»;

3. Разработка меню сайта;

4. Вставка объектов видео и тестов;

5. Тестирование программного обеспечения;

6. Внедрение сайта УМК по предмету «Математические методы» в учебный процесс.

программное обеспечение сайт браузер

ГЛАВА 1. ЮРИДИЧЕСКАЯ ЧАСТЬ

1.1 Особенности договора оказания услуг

Термины и определения

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

Техническое задание (ТЗ) - документ, создаваемый «ГАОУ СПО БАСК», который утверждается Сторонами в порядке, установленном Договором. После утверждения ТЗ становится неотъемлемой частью Договора и подлежит обязательному исполнению Сторонами (Приложение № 1 к настоящему Договору). ТЗ должно содержать следующие сведения:

сроки и стоимость выполнения этапов разработки Сайта;

задача (цель) проекта создания Сайта;

содержание Сайта;

технологические требования и функционал Сайта;

требования к системе администрирования Сайта;

требования к Дизайн-проекту Сайта;

перечень информационных материалов, документов и прочих сведений, необходимых ГАОУ СПО БАСК для исполнения обязательств по Договору, а также объем таких сведений, порядок и срок из предоставления Заказчиком;

модели работы пользователей с Сайтом;

иные сведения по усмотрению Сторон.

Дизайн-проект - уникальное графическое оформление сайта и способы представления информации. Дизайн-проект разрабатывается ГАОУ СПО БАСК и утверждается Заказчиком в порядке, установленном Договором.

Сборка Сайта - работы по созданию Сайта на основе утвержденного ТЗ. Сборка Сайта включает в себя:

разработку программы для ЭВМ;

обработку материалов (представленных Заказчиком, либо разработанных Веб-студией при исполнении Договора);

наполнение Сайта материалами;

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

1.2 Составление договора на оказание услуг по проектированию программного обеспечения

ГАОУ СПО БАСК в лице руководителя Амерханова Игоря Юмагуловича, действующего на основании Устава, с одной стороны, Миндавлетова Р.Р , в лице руководителя Амерханова И.Ю, действующий на Хайруллину Р.И, именуемую в дальнейшем «Заказчик», действующего на основании Устава, с другой стороны, вместе именуемы «Стороны» и каждая в отдельности «Сторона», заключили настоящий договор выполнения работ по разработке сайта по предмету «Математические методы».

ГАОУ СПО БАСК обязуется выполнить по заданию Заказчика работы по разработке Сайта Заказчика на русском языке, а также предоставить Заказчику права использования результатов интеллектуальной деятельности, созданных ГАОУ СПО БАСК в рамках Договора, а Заказчик обязуется выплатить ГАОУ СПО БАСК вознаграждение.

Сроки и порядок выполнения работ.

ГАОУ СПО БАСК обязуется приступить к выполнению работ по настоящему Договору с даты, следующей за датой зачисления на счет ГАОУ СПО БАСК авансового платежа.

Настоящий договор вступает в силу с момента подписания его обеими Сторонами и действует до полного исполнения Сторонами принятых на себя по Договору обязательств.

Каждая из Сторон вправе в одностороннем порядке расторгнуть Договор, уведомив об этом другую сторону в срок не позднее 7 (семи) рабочих дней до предполагаемой даты расторжения. В этом случае Стороны производят все взаимные расчеты. Оплате подлежат работы, фактически выполненные ГАОУ СПО БАСК на момент расторжения Договора.

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

Этапы договора

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

Этап 1

ГАОУ СПО БАСК осуществляет разработку ТЗ в соответствии с требованиями Заказчика и предварительным расчётом.

Готовое ТЗ направляется на согласование ответственному лицу Заказчика.

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

Согласованное ТЗ Сайта распечатывается Заказчиком на бумажном носителе в 2 (двух) экземплярах, подписывается уполномоченным лицом Заказчика и в течение 2 (двух) рабочих дней направляется в ГАОУ СПО БАСК

ГАОУ СПО БАСК в течение 2 (двух) рабочих дней с момента получения ТЗ на бумажном носителе, подписывает экземпляры и направляет 1 (один) экземпляр Заказчику.

В случае если Стороны в процессе согласования ТЗ Сайта не придут к общему решению, отведенный для выполнения работ по созданию Сайта в рамках отдельного этапа, Договор считается расторгнутым. При этом ГАОУ СПО БАСК обязуется вернуть Заказчику авансовый платеж, полученный согласно п. 5.2.1 Договора, за вычетом суммы вознаграждения за фактически выполненные работы.

Этап 1 считается законченным с момента получения Заказчиком утвержденного ТЗ Сайта на бумажном носителе.

Этап 2

ГАОУ СПО БАСК разрабатывает Дизайн-проект Сайта в соответствии с требованиями Заказчика и в течение срока, установленного утвержденным ТЗ.

ГАОУ СПО БАСК обязуется разработать не более 4 (четырех) вариантов Дизайн-проекта.

Разработанные ГАОУ СПО БАСК варианты Дизайн-проекта направляются на согласование Заказчику в электронном виде на электронный адрес.

Заказчик вправе выбрать один из представленных ГАОУ СПО БАСК вариантов Дизайн-проекта.

В течение 5 (пяти) рабочих дней с момента получения электронных вариантов Дизайн-проекта ответственные лица Сторон согласовывают выбранный Дизайн-проект в электронном виде путем обмена электронными сообщениями или при личной встрече и при необходимости вносят изменения в Дизайн-проект.

Согласованный Дизайн-проект распечатывается Заказчиком на бумажном носителе в 2 (двух) экземплярах, подписывается уполномоченным лицом Заказчика и в течение 2 (двух) рабочих дней направляется ГАОУ СПО БАСК.

ГАОУ СПО БАСК в течение 2 (двух) рабочих дней с момента получения Дизайн-проекта на бумажном носителе, подписывает экземпляры Дизайн-проекта и направляет 1 (один) экземпляр Заказчику.

В случае если Заказчик принимает решение отказаться от всех представленных вариантов Дизайн-проекта, Заказчик в течение 2 (двух) рабочих дней направляет ГАОУ СПО БАСК письменный отказ. В этом случае Стороны вправе расторгнуть договор, либо заключить дополнительное соглашение на выполнение работ по разработке дополнительного варианта Дизайн-проекта.

В случае если Стороны принимают решение о расторжении настоящего Договора, обязательства Сторон по Договору считаются прекращенными с момента подписания последней из Сторон соглашения о расторжении Договора. При этом авансовый платеж, полученный ГАОУ СПО БАСК согласно п. 5.2.1. Договора, Заказчику не возвращается.

Этап 2 считается законченным с момента получения ГАОУ СПО БАСК утвержденного Заказчиком экземпляра Дизайн-проекта на бумажном носителе.

Этап 3

ГАОУ СПО БАСК осуществляет Сборку Сайта в соответствии с требованиями и в течение срока, установленных утвержденным ТЗ и Договором.

Готовый Сайт направляется на согласование Заказчику путем предоставления доступа к подготовленному ГАОУ СПО БАСК Сайту, размещенному на сервере ГАОУ СПО БАСК.

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

По итогам согласования Сайта Заказчик формирует Акт передачи Сайта по форме Приложения № 2 к Договору на бумажном носителе в 2 (двух) экземплярах, подписывает уполномоченным лицом Заказчика и в течение 2 (двух) рабочих дней направляет ГАОУ СПО БАСК.

ГАОУ СПО БАСК в течение 2 (двух) рабочих дней с момента получения Акта передачи Сайта на бумажном носителе, подписывает экземпляры Акта передачи Сайта и направляет 1 (один) экземпляр Заказчику.

В случае если Стороны в процессе согласования Сайта не придут к общему решению в установленный Договором период времени, отведенный для выполнения работ по созданию Сайта в рамках отдельного этапа, Договор считается расторгнутым. При этом авансовый платеж, полученный ГАОУ СПО БАСК согласно п. 5.2.1. Договора, Заказчику не возвращается.

Этап 3 считается законченным с момента получения ГАОУ СПО БАСК подписанного Заказчиком экземпляра Акта передачи Сайта на бумажном носителе.

Этап 4

ГАОУ СПО БАСК осуществляет доработку Сайта в соответствии с утвержденным ТЗ.

Доработанный Сайт направляется на согласование Заказчику путем предоставления доступа к доработанному ГАОУ СПО БАСК Сайту, размещенному на сервере ГАОУ СПО БАСК.

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

По итогам согласования доработанного в соответствии с утвержденным ТЗ Сайта, ГАОУ СПО БАСК устанавливает Сайт на сервер Заказчика.

В течение 20 (двадцати) рабочих дней со дня следующего за днем установки Сайта на сервере Заказчика Стороны проводят проверочные испытания работоспособности Сайта на сервере Заказчика.

В случае наличия замечаний к работоспособности Сайта на сервере Заказчика, ответственное лицо Заказчика направляет замечания ГАОУ СПО БАСК на электронный адрес rom.mindavletov@yandex.ru

ГАОУ СПО БАСК в течение 4 рабочих дней устраняет выявленные замечания и повторно направляет Заказчику доработанный Сайт.

Этап 4 считается законченным, в случае если от Заказчика не поступило замечаний в течение 10 (десяти) рабочих дней с момента подписания Акта или последнего замечания.

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

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

ГАОУ СПО БАСК обязуется:

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

Выполнять работы, предусмотренные настоящим Договором, своими силами и средствами.

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

Своевременно предоставлять Заказчику доступ к результатам работ.

По требованию Заказчика информировать его о ходе работ.

Информировать Заказчика о:

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

иных, не зависящих от ГАОУ СПО БАСК обстоятельствах, которые могут повлиять на качество работы или невозможность ее завершения в срок, установленный Договором, ТЗ.

ГАОУ СПО БАСК вправе:

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

Заказчик обязуется:

В предусмотренные настоящим Договором сроки и в полном объеме оплачивать работы ГАОУ СПО БАСК.

Предоставлять полную и соответствующую действительности информацию, техническую документацию, необходимую ГАОУ СПО БАСК для исполнения Договора, в том числе при поступлении от ГАОУ СПО БАСК информации, указанной в п. 4.1.5 Договора.

Оказывать ГАОУ СПО БАСК содействие в выполнении работ по настоящему Договору.

Осуществлять приемку выполненных ГАОУ СПО БАСК работ.

Заказчик вправе:

Осуществлять проверку хода и качества выполнения работ ГАОУ СПО БАСК, не вмешиваясь в ее деятельность.

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

1.3 Форс-мажорные обстоятельства договора

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

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

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

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

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

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

ГЛАВА 2. ЭКОНОМИЧЕСКИЙ РАСЧЕТ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ САЙТА «МАТЕМАТИЧЕСКИЕ МЕТОДЫ»

2.1 Расчет периода изготовления программного продукта

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

Устанавливается оптимистическая оценка времени выполнения работы. Минимальное время (указано в колонке «Т min» табл.8.2), которое будет при самом благоприятном стечении обстоятельств.

Устанавливается также максимальное (указано в колонке «Т max» табл.6.1) время работы, которое имеет место при самом неблагоприятном стечении обстоятельств. Это время характеризуется большим, чем обычно числом неудач и т.п.

Таблица 6.1 - Расчет трудоемкости проектирования программного продукта

Наименование работы	Вероятностные оценки, дни
	Tmin	Tmax	Tож
Постановка проблемы	1	3	2
Описание предметной области	3	5	4
Проектирование электронного учебного сайта	15	25	20
Отладка электронного учебного сайта	3	7	5
Оформление документов	4	8	6
Общая продолжительность работы составляет:	26	48	37

tож =

гдеТож - ожидаемое время продолжительности работ

Тmin - оценка при наиболее благоприятных условиях

Tmax - оценка при наиболее неблагоприятных условиях

Ожидаемое время выполнения работ по разработке ПП «Электронный сайт по предемету «Математические методы»» = 37 дней.

2.2 Расчет стоимости программного продукта

Процент рентабельности (условно) - 20% ,

Прибыль рассчитывается по формуле:

П = = 21146 (руб.)

Цена программного продукта равна сумме полной себестоимости и прибыли:

Ц = Сполн + П(9.5.10)

Ц = 108531,3435+ 21146 = 132877 (руб.)

Цена программного продукта с НДС:

НДС =

НДС =

Цена = 132877+ 26575,4 = 156452,4(руб.)

Стоимость программного продукта составляет 156452 рублей.

2.3 Расчет себестоимости программного продукта

Себестоимость разработки системы - это, как правило, совокупность затрат на разработку программного продукта. Затраты на разработку программы подразделяются на следующие статьи расходов: материальные затраты, основная заработная плата, ФСЗН, накладные расходы.

Расчет материальных затрат

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

Таблица 6.2 - Расчет стоимости материальных затрат

Наименование материала	Количество комплектов, шт.	Цена одного комплекта, руб.	Транспортные затраты, руб.	Сумма затрат, руб.
Компакт-диск	1	40	0	4 500
Бумага	1	200	0	32 800
ПО	1	15000	0	3 200
Всего	-	-	-	40 500

Расчет заработной платы программиста

Расчет ЗП программиста производится в соответствии с трудоемкостью разработки программного продукта.

Данные для расчета:

- ставка 1 разряда -240 000 руб.

- разряд 10

- тарифный коэффициент 2.43

- с 10-го до 11-го разряда 1.628

Часовая тарифная ставка (Сч) определяется:

Сч =

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

Сч = = 5394,6 рубля в час

Основная заработная плата программиста за разработку программы составит:

ЗПосн = Сч • Тож (6.3)

ЗПосн = 5394,6 * (37*8) = 5394,6 *259 = 1596801,6 (руб.)

35Дополнительная заработная плата:

ЗПдоп = (6.4)

ЗПдоп = = 23520,24 (руб.)

Итого затраты на оплату труда:

ЗПобщ = ЗПосн + ЗПдоп(6.5)

ЗПобщ = 156801,6 + 239520,24 = 186321,84 (руб.)

Расчет единого социального налога

При ставке 35% от общей суммы заработной платы, ФСЗН высчитывается по формуле:

ФСЗН = = 64712,644 (руб.)

Расчет накладных расходов

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

Таблица 6.3 - Затраты на электроэнергию

Вид оборудования	Мощность, кВт	Стоимость, 1 кВт/час (Без НДС)	Время работы оборудования, Тож час	Сумма затрат, руб.
Ноутбук	0,05	630	296	18480
Итого	-	-	-	18480

В таблице 6.3 выполнены расчеты по затрате ресурсов на электроэнергию по формуле:

Сумма = (М • С) • Т, (6.7)

где М - Мощность, кВт

С - Стоимость , 1 кВт/час

Т - Время работы оборудования, Тож час

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

Таблица 6.4 - Амортизационные отчисления

Вид оборудования	Первоначальная стоимость, руб.	Срок полезного использования	Норма амортизации %	Сумма амортизационных отчислений, руб.
Ноутбук	4300000	36	2,7	11600
Итого	-	1,3	-	15030

Сумма амортизационных отчислений за период разработки, определяются по следующим формулам:

Амес = = 16100

где Сп - первоначальная стоимость оборудования, руб.;

На - месячная норма амортизации, %;

Амортизационные отчисления за период разработки программного продукта:

(116100/22)*37 = 195259(руб.)

Прочие накладные расходы - 20% от основной заработной платы:

Размещено на http://www.allbest.ru/

Сумма накладных расходов = затраты на электроэнергию + амортизационные отчисления + прочие накладные расходы.

Сумма накладных расходов = 815,5 + 19529+ 27940,28 = 48257,78 (руб.)

Расчет калькуляции затрат на разработку программного продукта

Расчет калькуляции затрат наглядно представлен в таблице «Калькуляция затрат на разработку программного продукта».

Таблица 6.5 - Калькуляция затрат на разработку программного продукта

Статья затрат	Единицы измерения	Сумма затрат, руб.
Материальные затраты	руб.	40500
Отчисления на социальные нужды (ФСЗН)	руб.	56273,5635
Накладные расходы, в т.ч. амортизация dobavit seroku zarabotnoj	руб.	48257,78
Итого:	-	108531,3435

ГЛАВА 3. ПРОЕКТНАЯ ЧАСТЬ

3.1 Алгоритм создания программного продукта

ШАГ 1 НАЧАЛО

ШАГ 2 Проанализировать и выявить недостатки

ШАГ 3 Процесс поиска необходимой информации

ШАГ 4 Формирование структуры электронного сайта

ШАГ 5 Формирование разделов электронного учебного пособия в виде web-сайта

ШАГ 6 Загрузка видеоматериала

ШАГ 7 Создания теста для самопроверки

ШАГ 8 Тестирование электронного учебного пособия в виде web-сайта

ШАГ 9 Эксплуатация и внедрение электронного учебного пособия в виде web-сайта в интернет.

ШАГ 10 КОНЕЦ



Рис 3.0 Алгоритм разработки электронного сайта

3.2 Структура создания программного продукта

Размещено на http://www.allbest.ru/

Рис 3.1 Структура сайта «Математические методы»

Структура сайта и краткое описание

Главная страница (обложка сайта).

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

Контентная область первой страницы делится на разделы:

- вертикальное меню, включает в себя «Главная», «Лекции», «Экзаменационные вопросы», «Задачи в условиях неопределенности», «Основы моделирования», «Детерминированные задачи», «Тесты», «Видеоматериал»;

Главная

В разделе "Главная" (Рис.3.2) электронного сайта пользователь может ознакомиться с краткой характеристикой предмета. Данная страница содержит основную тему предмета и основные положения описываемого источника.

Рис 3.2 Раздел «Главная»

Лекции

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

Рис 3.3 Раздел «Лекции»

Основы моделирования

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

Рис 3.4 Раздел «Основы моделирования»

Детерминированные задачи

В разделе «Детерминированные задачи»(Рис 3.5) студент может изучить линейное программирование которые характеризуются линейной зависимостью между переменными и линейной целевой функцией и мн другое.



Рис 3.5 Раздел «Детерминированные задачи»

Задачи в условиях неопределенности

В данном подразделе (Рис 3.6) пользователь может изучить основные понятия марковских процессов. Какие бывают марковские процессы и методы их решения.

Рис 3.6 Раздел «Задачи в условиях неопределенности

Экзаменационные вопросы

В разделе «Экзаменационные вопросы» (Рис 3.7) студент может предварительно изучить экзаменационные вопросы по данному предмету и подготовиться к экзамену.

Рис 3.7 Раздел «Экзаменационные вопросы»

Видеоматериал

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



Рис 3.7 Раздел «Видеоматериал»

3.3 Конструктивная часть создания программного продукта

Карта электронного сайта - это полный каталог всех разделов сайта, просмотреть который можно на схеме 2

Схема 2 Карта электронного сайта

Структура административной части сайта

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

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

Структура пользовательской части сайта

Для непосредственного вывода информации в браузер используются 6 файлов. Для идентификации информации, которую нужно отобразить на странице, то есть для связи между этими файлами, используются GET и POS переменные.

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

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

- идентификаторов категорий;

- идентификаторов разделов;

- идентификатора для выхода с сайта;

- идентификатора для редактирования учетных данных;

- передачи поискового запроса из формы;

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

Итог

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

ГЛАВА 4. ТЕСТИРОВАНИЕ ПРОГРАММНОГО ПРОДУКТА

Тестирование программного обеспечения (software testing)- это процесс анализа или эксплуатации программного обеспечения с целью выявления дефектов.

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

Согласно этому определению, тестирование предусматривает "анализ" или "эксплуатацию" программного продукта. Тестовая деятельность, связанная с анализом результатов разработки программного обеспечения, называется статическим тестированием (static testing). Статическое тестирование предусматривает проверку программных кодов, сквозной контроль и проверку программы без запуска па машине, т.е. проверку за столом (desk checks). В отличие от этого, тестовая деятельность, предусматривающая эксплуатацию программного продукта, носит название динамического тестирования (dynamic testing). Статическое и динамическое тестирование дополняют друг друга, и каждый из этих типов тестирования реализует собственный подход к выявлению ошибок.

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

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

Цели и задачи тестирования программного обеспечения

Цели тестирования:

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

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

Провести полное тестирование приложения за короткий срок.

Задачи тестирования:

Проверить, что система работает в соответствии с определенными временами отклика клиента и сервера.

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

Проверить работу пользовательских интерфейсов

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

При проектировании тестов свести к минимуму переработку тестов при возможных изменениях приложения.

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

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

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

4.1 Метод «белого ящика»

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

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

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

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

2. Проверяют все логические решения на предмет того, истины они или ложны.

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

4. Исследуют структуры внутренних данных с целыо проверки их достоверности.

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

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

Методы тестирования на основе стратегии белого ящика:

Ввод неверных значений. При вводе неверных значений тестировщик заставляет коды возврата показывать ошибки и смотрит на реакцию кода. Это хороший способ моделирования определенных событий, например переполнения диска, нехватки памяти и т.д. Популярным методом является замена alloc() функцией, которая возвращает значение NULL в 10% случаев с целью выяснения, сколько сбоев будет в результате. Такой подход еще называют тестированием ошибочных входных данных. При таком тестировании проверяется обработка как верных, так и неверных входных данных. Тестировщики могут выбрать значения, которые проверяют диапазон входных/выходных параметров, а также значения, выходящие за границу диапазона.

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

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

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

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

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

Исследование покрытия. При выборе инструмента для исследования покрытия важно, чтобы группа тестирования проанализировала тип покрытия, необходимый для приложения. Исследование покрытия можно провести с помощью различных технологий. Метод покрытия операторов часто называют С1, что также означает покрытие узлов. Эти измерения показывают, был ли проверен каждый исполняемый оператор. Данный метод тестирования обычно использует программу протоколирования (profiler) производительности.

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

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

4.2 Метод «черного ящика»

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

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

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

Неверная или пропущенная функциональность

Ошибки интерфейса

Проблемы удобства использования

Методы тестирования на основе Автоматизированные инструменты

Ошибки в структурах данных или ошибки доступа к внешним базам данных

Проблемы снижения производительности и другие ошибки производительности

Ошибки загрузки

Ошибки многопользовательского доступа

Ошибки инициализации и завершения

Проблемы сохранения резервных копий и способности к восстановлению работы

Проблемы безопасности

Методы тестирования на основе стратегии черного ящика

Эквивалентное разбиение. Исчерпывающее тестирование входных данных, как правило, неосуществимо. Поэтому следует проводить тестирование с использованием подмножества входных данных.

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

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

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

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

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

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

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

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

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

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

4.3 Тестирование программного продукта разными браузерами

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

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

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

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

- удаление комментариев:

- редактирование комментариев;

- добавление материалов;

- редактирование разделов;

- удаление глав и подразделов;

- добавление категорий;

- удаление категорий;

- редактирование категорий;

- регистрация пользователя;

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

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

- редактирование регистрационных данных в административной части сайта;

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

- восстановление пароля;

- поиск по сайту;

...