Достоинства:

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

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

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

Недостатки:

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

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

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

Страница сайта изображена ниже на рисунке. Она состоит из:

основного меню,

дополнительных меню,

основного поля для ввода текста,

поле для дополнительной информации.



Макет страницы сайта «Класс профессора Лисова Олега Ивановича»

Система меню

Меню сайта представляет собой следующую структуру:

Структура меню сайта

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

Для входа в систему преподавателю нужно иметь права администратора. После получения таких прав ему нужно авторизоваться на странице администрирования.



Макет страницы авторизации преподавателя

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

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

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

пароль слушателя,

ФИО слушателя,

его дополнительные данные,

добавлять и удалять слушателя,

изменять график работ слушателя.

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

Интерфейс пользователя

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

Макет страницы авторизации слушателя

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

Макет персональной страницы слушателя

Работа со сторонними посетителями сайта

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

Введенная информация попадает на заданный e-mail преподавателя.

Макет страницы взаимосвязи со сторонними посетителями сайта

Форум

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

Макет страницы форума на сайте

Макет страницы регистрации нового пользователя в форуме

Администратор помимо прочих прав имеет возможность удалять сообщения.

Алгоритмы работы скриптов представлены в приложении 1.

Создание электронного учебника

Создание электронного учебника заключается в создании текстовых и звуковых файлов. Это:

- набивка и обработка текста,

- создание звукового файла с помощью Magic Goody,

- обработка звукового файла с помощью Sound Forge,

- создание структуры учебного пособия и прикрепление созданных фалов.

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



Макет страницы электронного пособия

Отладка процедур и функций интеллектуальной системы

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

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

- отсутствие полностью определенного эталона (программы), которому должны соответствовать все результаты тестирования проверяемой программы,

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

- относительно невысокая степень формализации критериев качества процесса тестирования и достигаемого при этом качества объектов тестирования,

- наличие в программах вычислительных и логических компонент.

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

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

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

Общая структура отладки программ

Процесс отладки программ включает:

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

- тестирование программ,

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

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

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

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

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

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

- тестирование для обнаружения ошибок в программе,

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

- тестирование для контроля выполненных корректировок программ и данных.

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

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

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

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

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

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

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

Default die handler restored.

Loading DB routines from perl5db.pl version 1.07

Editor support available.

Enter h or `h h' for help, or `man perldebug' for more help.

main::(test.pl:7): my $dbh = DBI->connect('dbi:mysql:lena','egosteva','password') or die;

Окно терминала с запущенной сессией отладки скрипта

С помощью команд «n» (next, выполнение до следующей конструкции текущей программы, без выполнения отладки вызовов подпрограмм), «s» (step into, выполнение до следующей конструкции языка, с заходом в подпрограммы) трассируем выполнение скрипта до интересующего нас места. Ввод пустой строки означает повторение предыдущей команды «n» или «s».

DB<1> n

main::(test.pl:8): printTalks($dbh,1);

DB<1> s

main::printTalks(common.cgi:154): my ( $dbh, $student) = @_;

DB<1> n

main::printTalks(common.cgi:156): my $sth = $dbh->prepare(

main::printTalks(common.cgi:157): 'select id,upper_id,creator_type,creator_id,descr,add_date from talks where student_id='.$student.' order by add_date'

main::printTalks(common.cgi:158): );

DB<1>

main::printTalks(common.cgi:159): unless( $sth && $sth->execute ) {

DB<1>

main::printTalks(common.cgi:164): my @talks=();

DB<1>

main::printTalks(common.cgi:165): my %admins=();

DB<1>

main::printTalks(common.cgi:166): my %studs=();

DB<1>

main::printTalks(common.cgi:167): while( my @arr=$sth->fetchrow_array ) {

DB<1>

main::printTalks(common.cgi:168): $arr[3] = int($arr[3]);

DB<1>

main::printTalks(common.cgi:169): push @talks, [ @arr ];

DB<1>

main::printTalks(common.cgi:170): if( $arr[2] eq 'S' ) {

DB<1>

main::printTalks(common.cgi:174): $admins{$arr[3]} = 1;

DB<1>

main::printTalks(common.cgi:167): while( my @arr=$sth->fetchrow_array ) {

DB<1> n

main::printTalks(common.cgi:168): $arr[3] = int($arr[3]);

DB<1>

main::printTalks(common.cgi:169): push @talks, [ @arr ];

DB<1>

main::printTalks(common.cgi:170): if( $arr[2] eq 'S' ) {

С помощью встроенной команды «x» печатаем содержимое интересующих нас переменных вместе с их типами. Нас интересует правильно ли заполнен массив @talks.

DB<1> x @talks

0 ARRAY(0x83ced88)

0 1

1 0

2 'A'

3 1

4 'Эх, хорошо в стране советской жить!!!'

5 '2002-03-31 05:11:01'

1 ARRAY(0x83cedd0)

0 2

1 1

2 'S'

3 1

4 'И чего хорошего???'

5 '2002-03-31 05:11:01'

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

DB<2> n

main::printTalks(common.cgi:171): $studs{$arr[3]} = 1;

DB<2>

main::printTalks(common.cgi:167): while( my @arr=$sth->fetchrow_array ) {

С помощью команды «l» (listing, распечатка текста программы) выясняем номер строки на которой находится интересующий нас код. В данном случае нас интересует, будет ли выполняться блок if, начинающийся на строке 178.

DB<2> l

167==> while( my @arr=$sth->fetchrow_array ) {

168: $arr[3] = int($arr[3]);

169: push @talks, [ @arr ];

170: if( $arr[2] eq 'S' ) {

171: $studs{$arr[3]} = 1;

172 }

173 else {

174: $admins{$arr[3]} = 1;

175 }

176 }

DB<2> l

177: $sth->finish;

178: if( %admins ) {

179: $sth=$dbh->prepare('select id,full_name from admin where id in ('.join(',',keys %admins).')');

180: unless( $sth && $sth->execute ) {

181: my $errstr = $dbh->errstr;

182: print "Content-Type: text/plain\n\nОшибка выборки переписки: $errstr\n";

183: exit 0;

184 };

185: %admins = ();

186: while( my @arr = $sth->fetchrow_array ) {

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

DB<2> c 177

main::printTalks(common.cgi:177): $sth->finish;

DB<3> n

main::printTalks(common.cgi:178): if( %admins ) {

DB<3>

main::printTalks(common.cgi:179): $sth=$dbh->prepare('select id,full_name from admin where id in ('.join(',',keys %admins).')');

DB<3>

main::printTalks(common.cgi:180): unless( $sth && $sth->execute ) {

Аналогичным образом проверяем, передаётся ли управление внутрь блока if( %stud ) начинающегося на строке 190.

DB<3> l

180==> unless( $sth && $sth->execute ) {

181: my $errstr = $dbh->errstr;

182: print "Content-Type: text/plain\n\nОшибка выборки переписки: $errstr\n";

183: exit 0;

184 };

185: %admins = ();

186: while( my @arr = $sth->fetchrow_array ) {

187: $admins{$arr[0]} = $arr[1];

188 }

189: $sth->finish;

DB<3> c 189

main::printTalks(common.cgi:189): $sth->finish;

DB<4> n

main::printTalks(common.cgi:191): if( %studs ) {

Далее нас интересует правильность работы подпрограммы печати дерева переговоров. Для этого используем серию команд «n», «l» и «c», чтобы перейти на точку вызова подпрограммы, расположенную на строке 204.

DB<4> l

191==> if( %studs ) {

192: $sth=$dbh->prepare('select id,full_name from students where id in ('.join(',',keys %studs).')');

193: unless( $sth && $sth->execute ) {

194: my $errstr = $dbh->errstr;

195: print "Content-Type: text/plain\n\nОшибка выборки переписки: $errstr\n";

196: exit 0;

197 };

198: %studs = ();

199: while( my @arr = $sth->fetchrow_array ) {

200: $studs{$arr[0]} = $arr[1];

DB<6> c 198

main::printTalks(common.cgi:198): %studs = ();

DB<7> n

main::printTalks(common.cgi:199): while( my @arr = $sth->fetchrow_array ) {

DB<7> l

199==> while( my @arr = $sth->fetchrow_array ) {

200: $studs{$arr[0]} = $arr[1];

201 }

202: $sth->finish;

203 }

204: printSubTalks(0,\%admins,\%studs,\@talks);

205 }

206

207 sub printSubTalks($$$$) {

208: my ( $parent,$adm,$std,$talks) = @_;

DB<7> c 204

main::printTalks(common.cgi:204): printSubTalks(0,\%admins,\%studs,\@talks);

С помощью команды «s» переходим в подпрограмму и с помощью команды «n» трассируем выполнение программы при печати одного сообщения.

DB<8> s

main::printSubTalks(common.cgi:208):

208: my ( $parent,$adm,$std,$talks) = @_;

DB<8> n

main::printSubTalks(common.cgi:209):

209: my $found = 0;

DB<8>

main::printSubTalks(common.cgi:210):

210: for( my ($cntr,$lim)=(0,scalar @$talks);$cntr<$lim;$cntr++) {

DB<8> l

210==> for( my ($cntr,$lim)=(0,scalar @$talks);$cntr<$lim;$cntr++) {

211: my ( $id,$cur_parent,$cr_type,$cr_id,$descr,$date ) = @{$$talks[$cntr]};

212: next if $cur_parent != $parent;

213: unless( $found ) {

214: print "<UL>\n";

215: $found = 1;

216 }

217: if( $cr_type eq 'S' ) {

218: if( exists $$std{$cr_id} ) {

219: $cr_id = $$std{$cr_id};

DB<8> n

main::printSubTalks(common.cgi:211):

211: my ( $id,$cur_parent,$cr_type,$cr_id,$descr,$date ) = @{$$talks[$cntr]};

DB<8>

main::printSubTalks(common.cgi:211):

211: my ( $id,$cur_parent,$cr_type,$cr_id,$descr,$date ) = @{$$talks[$cntr]};

DB<8>

main::printSubTalks(common.cgi:212):

212: next if $cur_parent != $parent;

DB<8>

main::printSubTalks(common.cgi:213):

213: unless( $found ) {

DB<8>

main::printSubTalks(common.cgi:214):

214: print "<UL>\n";

DB<8>

<UL>

main::printSubTalks(common.cgi:215):

215: $found = 1;

DB<8>

main::printSubTalks(common.cgi:217):

217: if( $cr_type eq 'S' ) {

DB<8>

main::printSubTalks(common.cgi:226):

226: if( exists $$adm{$cr_id} ) {

DB<8>

main::printSubTalks(common.cgi:227):

227: $cr_id = $$adm{$cr_id};

DB<8>

main::printSubTalks(common.cgi:233):

233: print '<li><b>',CGI::escapeHTML($cr_id),'</b>(',$date,'): ',

234: CGI::escapeHTML($descr),"\n";

DB<8>

(offline mode: enter name=value pairs on standard input)

<li><b>Олег Иванович Лисов</b>(2002-03-31 05:11:01): Эх, хорошо в стране советской жить!!!

main::printSubTalks(common.cgi:235):

235: printSubTalks($id,$adm,$std,$talks);

DB<8> n

<UL>

<li><b>Елена Валерьевна Гостева</b>(2002-03-31 05:11:01): И чего хорошего???

<UL>

<li><b>Олег Иванович Лисов</b>(2002-03-31 05:11:01): Эх, хорошо стране полезным быть!!!

<UL>

<li><b>Елена Валерьевна Гостева</b>(2002-03-31 05:11:01): Так чего же хорошего в этом???

</UL>

<li><b>Олег Иванович Лисов</b>(2002-03-31 05:11:01): Дык просто хорошо.

</UL>

</UL>

main::printSubTalks(common.cgi:210):

210: for( my ($cntr,$lim)=(0,scalar @$talks);$cntr<$lim;$cntr++) {

DB<8> n

main::printSubTalks(common.cgi:211):

211: my ( $id,$cur_parent,$cr_type,$cr_id,$descr,$date ) = @{$$talks[$cntr]};

DB<8> n

main::printSubTalks(common.cgi:211):

211: my ( $id,$cur_parent,$cr_type,$cr_id,$descr,$date ) = @{$$talks[$cntr]};

DB<8>

main::printSubTalks(common.cgi:212):

212: next if $cur_parent != $parent;

DB<8>

main::printSubTalks(common.cgi:210):

210: for( my ($cntr,$lim)=(0,scalar @$talks);$cntr<$lim;$cntr++) {

Убедившись в корректной работе подпрограммы с помощью команды «c» продолжаем выполнение программы до завершения.

DB<8> c

<li><b>Елена Валерьевна Гостева</b>(2002-03-31 05:11:01): a1aaa1aa

<UL>

<li><b>Елена Валерьевна Гостева</b>(2002-03-31 05:11:01): bbbbbbbbb

<UL>

<li><b>Олег Иванович Лисов</b>(2002-03-31 05:11:01): ccccccc

<UL>

<li><b>Елена Валерьевна Гостева</b>(2002-03-31 05:11:01): qewr asdf qwer zcxvasd qerasdf zcv qwer zcxv qewr zcv qwer cv qwer zcv qwer zxcv qwer zxcv qewr zxcv wer vqwe5 zxadfqw4 zxcvq asdfg e5qtqz zadsf qewr adf qer adf qwer adf qwer dfasdf qewr gdfgdfg rt qer asdf qwer sadf qewr adf qwer adf qwer dasf qewr fsa erqwerqwer adfadsfasd qewrerqwe asdfasfsa erqwraf qewrqwer adsfasfasd qerqwer adfasdfas

</UL>

<li><b>Олег Иванович Лисов</b>(2002-03-31 05:11:01): ddddddddd

</UL>

</UL>

</UL>

Debugged program terminated. Use q to quit or R to restart,

use O inhibit_exit to avoid stopping after program termination,

h q, h R or h O to get additional info.

После завершение программы выходим из отладочного интерпретатора с помощью команды «q» (quit, завершить работу).

egosteva@zeta:~/lena.tvc.ru/cgi-bin$

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

Раздел 2. Технологическая часть

2.1 Общие принципы тестирования программ

Одним из самых сложных и трудоемких этапов технологического процесса разработки программ является их тестирование и отладка. Как известно, при создании типичного программного проекта около 50% общего времени и более 50% общей стоимости расходуется на проверку (тестирование) разрабатываемой системы и ее отладку.

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

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

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

Существует два основных подхода к тестированию.

Тестирование программы как «черного ящика».

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

Тестирование программы как «белого ящика».

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

Тестирование модулей

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

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

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

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

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

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

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

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

Тестирование и отладка сайта

Сайт проектировался в виде следующей структуры взаимодействующих модулей и скриптов:

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

add_message.cgi - скрипт отображения списка слушателей с возможностью переход на страницу редактирования параметров слушателя.

add_prep.cgi - скрипт добавления нового преподавателя.

add_sch_waypoint.cgi - скрипт добавления пунктов в план работы студента. После добавления переадресует браузер к странице инициировавшей запрос.

add_student.cgi - скрипт добавления нового слушателя. При успешном добавлении студента переадресует браузер на страницу, инициировавшую запрос.

change-prep-attr.cgi - изменение параметров преподавателя.

change-student-attr.cgi - изменение параметров слушателя. Менять можно почти все, кроме логина. При успешном добавлении студента переадресует браузер на страницу, инициировавшую запрос.

edit_prep.cgi - скрипт создания формы редактирования параметров преподавателя.

delete_student.cgi - скрипт удаления слушателя.

delete_prep.cgi - скрипт удаления преподавателя.

delete_message.cgi - скрипт удаления сообщения из списка форума преподавателя со слушателем.

common.cgi - библиотека общих функций скриптов сайта.

close_sch_waypoint.cgi - скрипт для закрытия пункта плана работ. При успешном добавлении студента переадресует браузер на страницу, инициировавшую запрос.

change_student_attr.cgi - изменение параметров слушателя.

login_st.cgi - скрипт авторизации пользователя.

list_talks_to_append.cgi - печать сообщения, на которое отвечает пользователь.

list_students.cgi - скрипт отображения списка слушателей с возможностью перехода на страницу редактирования параметров слушателя. Также отображается форма добавления нового слушателя.

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

get_users.cgi - скрипт отображения списка слушателей.

get_schedule.cgi - скрипт отображения данных слушателя и его плана работ.

get_file.cgi - скрипт выдачи файла, присоединенного к сообщению.

edit_student.cgi - скрипт создания формы редактирования параметров слушателя.

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

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

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

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

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

Нисходящее тестирование

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

При выборе последовательности тестирования модулей рекомендуется придерживаться двух основных правил:

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

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

Восходящее тестирование

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

Подготовка к тестированию

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

Тестирование модуля common.cgi

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

Тестирование скрипта login_st.cgi

Данный скрипт производит проверку логина и пароля, введённых пользователем системы. Для тестирования скрипта необходимо включить в браузере запрашивание разрешения на использования сеансовых ключей (cookie). Далее, при заполнении формы авторизации на страницах авторизации преподавателя или слушателя и отправки данных формы на сервер сайта, при получении ответа скрипта авторизации login_st.cgi браузер отображает диалог подтверждения использования ключей cookie, в котором отображается содержимое ключа. Ошибки работы скрипта выявляются сравнением содержимого ключа и исходных данных.

Тестирование остальных скриптов

change_student_attr.cgi - изменение параметров слушателя.

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

list_talks_to_append.cgi - печать сообщения, на которое отвечает пользователь.

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

list_students.cgi - скрипт отображения списка слушателей с возможностью перехода на страницу редактирования параметров слушателя. Также отображается форма добавления нового слушателя.

Визуально, сравнением содержимого таблицы слушателей с отображаемыми данными.

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

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

get_users.cgi - скрипт отображения списка слушателей.

Визуально, сравнением содержимого таблицы слушателей с отображаемыми данными.

get_schedule.cgi - скрипт отображения данных слушателя и его плана работ.

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

get_file.cgi - скрипт выдачи файла, присоединенного к сообщению.

Созданием сообщения с вложенным файлом, выборки файла из этого сообщения, сохранением его на диск и сравнением с исходным файлом.

edit_student.cgi - скрипт создания формы редактирования параметров слушателя.

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

Раздел 3. Организационно-экономическая часть

3.1 Анализ конкурентоспособности разрабатываемого программного продукта

Оценка конкурентоспособности программного продукта

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

Решающим фактором коммерческого успеха товара является конкурентоспособность.

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

Данный раздел дипломного проекта предполагает собой оценку конкурентоспособности интеллектуальной системы поддержки обучения «Класс профессора Лисова Олега Ивановича», как учебного комплекса, используемого при подготовке специалистов по тьюторной методике в процессе обучения студентов и аспирантов кафедры ИПОВС МИЭТ (ТУ).

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

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

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

В связи с этим оценка конкурентоспособности программного продукта «Класс профессора Лисова» проводится в сравнении с аналогичными учебно-методическими комплексами, представленными в других (традиционных) формах обучения.

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

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

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

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

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

Трехуровневая модель товара (ядерная модель):

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

II - результат разработки товара - замысла.

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

Жизненный цикл товара - очень важная маркетинговая концепция.

Жизненный цикл - это совокупность стадий существования товара от зарождения до снятия с производства.

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

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

а - константа, определяемая на основе статистики,

m - наклон кривой,

b - константа,

y - объем продаж.

На рисунках классически вариант жизненного цикла. Существует несколько его разновидностей. Виды:

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

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

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

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

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

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

, где

С - затраты потребителей,

Э - полезность.

Оценка конкурентоспособности товара, планируемого к продаже, включает следующие этапы:

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

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

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

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

,

Jн - свободный индекс по нормативным параметрам

, l={0,1}

Jтп - способ, подход к определению технических параметров

,

pi - частный параметрический индекс. Отражает степень удовлетворения потребителя.

Идеальный товар - товар, который на 100% удовлетворяет потребителя, если xi<xiидеал товара

Для оценки экономических характеристик используется «цена потребления» - сумма всех затрат потребителя

bi - весомость состояний цены (значимость)

gi - индекс по экономическим характеристикам

,

Если Ku>1, анализируемое изделие превосходит по конкурентоспособности образец, если Ku<1 - уступает, если Ku=1 - находится на одном уровне. Наша задача получить Ku1.

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

Конкурентоспособность товара можно оценить по схеме:

Оценка конкурентоспособности товара

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

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

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

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

Показатели конкурентоспособности

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

Величины экономических параметров определяются ценой изделия Ц1, расходами на его транспортировку Ц2, установку Ц3, обучение персонала Ц7, эксплуатацию Ц4, ремонт Ц5, техническое обслуживание Ц6, налоги Ц8, страховые взносы Ц9 и т.д. В совокупности эти расходы составляют цену потребления Ц - объем средств, нужных потребителю в течение всего срока службы товара:

Чтобы оценить соотношение параметров конкретного изделия и параметров образца, необходимо эти данные количественно определить. Каждый «жесткий» параметр имеет определенную величину, выраженную в некоторых единицах - киловаттах, миллиметрах и т.д. Эта величина позволяет покупателю сделать вывод, насколько свойство изделия, выраженное данным параметром, отвечает его потребностям. Степень удовлетворения выражают в форме процентного отношения фактической величины параметра к той величине, при которой потребность удовлетворяется на 100%. Аналогичный расчет проводят по всем количественно оцененным параметрам, получая для каждого параметрический индекс.

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

3.2 Оценка конкурентоспособности тьюторного обучения

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

Выбор времени обучения.

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