«Е. П. Моргунов О. Н. Моргунова Технология программирования Курсовое проектирование Красноярск – 2011 Министерство образования и науки Российской Федерации Сибирский государственный аэрокосмический университет имени ...»

СИБИРСКИЙ ГОСУДАРСТВЕННЫЙ

АЭРОКОСМИЧЕСКИЙ УНИВЕРСИТЕТ

имени академика М. Ф. Решетнева

Е. П. Моргунов

О. Н. Моргунова

Технология

программирования

Курсовое проектирование

Красноярск – 2011

Министерство образования и науки Российской Федерации

Сибирский государственный аэрокосмический университет

имени академика М. Ф. Решетнева Е. П. Моргунов О. Н. Моргунова Технология программирования Курсовое проектирование Рекомендовано к изданию научно-методической комиссией института информатики и телекоммуникаций Красноярск – 2011 УДК 004.4 ББК 32.973.26 М 79 Рецензент:

доктор технических наук, профессор А. Н. Антамошкин (Сибирский государственный аэрокосмический университет) Моргунов, Е. П.

Технология программирования. Курсовое проектирование :

М учеб.-метод. пособие / Е. П. Моргунов, О. Н. Моргунова ; Сиб. гос.

аэрокосмич. ун-т. – Красноярск, 2011. – 87 с.

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

Пособие предназначено для студентов, обучающихся по направлениям 230100 – «Информатика и вычислительная техника» и 230200 – «Информационные системы». Оно может быть полезно широкому кругу студентов, знакомых с основами программирования, впервые приступающих к разработке программных продуктов.

УДК 004. ББК 32.973. © Сибирский государственный аэрокосмический университет имени академика М. Ф. Решетнева, © Е. П. Моргунов, О. Н. Моргунова, Оглавление 1. Введение

2. Выбор темы курсового проекта

2.1. Факторы, влияющие на выбор темы

2.2. Формулирование названия курсового проекта

3. Требования к выполнению и оформлению работы

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

3.1.1. Состав документации и общие требования к ее оформлению... 3.1.2. Объем работы

3.2. Титульный лист

3.3. Содержание

3.4. Введение

3.5. Состав творческой группы

3.6. План выполнения разработки

3.7. Документ-концепция

3.8. Архитектура и системные требования

3.9. Технический проект

3.10. Исходные тексты программ

3.11. Методика тестирования

3.12. Руководство пользователя

3.13. Руководство программиста

3.14. Заключение

3.15. Список использованной литературы

3.16. Приложения

4. Заключение

5. Рекомендуемая литература

Приложения

Приложение 1. Документ-концепция

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

Приложение 3. Описание шага разработки при использовании пошаговой модели разработки

Приложение 4. Стандарт кодирования

Приложение 5. Описание структуры базы данных

Приложение 6. Титульный лист

Приложение 7. Содержание

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

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

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

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

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

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

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

2.1. Факторы, влияющие на выбор темы Что такое фактор? Это то, что является действующей (движущей) силой или существенным обстоятельством в какой-то ситуации, в каком-то процессе, например, в процессе принятия важного решения.

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

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

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

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

А теперь рассмотрим факторы, которые имеют место в данной ситуации.

1. Ваши перспективные планы. Если вы собираетесь связать свою жизнь с наукой, то планируйте поступать в магистратуру и далее – в аспирантуру. В таком случае имеет смысл подумать о выборе темы, которая будет вам интересна все годы обучения на нашем факультете и сможет впоследствии стать темой вашей магистерской диссертации, а в перспективе войдет составной частью и в диссертацию кандидатскую. Естественно, такая тема должна содержать в себе некоторую научную составляющую. Это не может быть, к примеру, очередной Интернет-магазин. Более ориентированы на науку такие темы, как, например: проблемы машинного перевода с иностранных языков, математическое моделирование в экономике, теоретические проблемы компиляторов, разработка проблемноориентированного языка программирования. Известно, что российский физик, лауреат Нобелевской премии Жорес Алферов начал заниматься той темой, за которую ему и была присуждена премия, еще учась на третьем курсе института. Этот пример говорит о пользе более ранней специализации. Так что выбирайте себе тему с учетом дальнейших перспектив, а не на один семестр.

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

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

Если вас интересует только программирование (или вам так кажется) и вы хотели бы заниматься серьезными разработками, тогда вам нужно подумать над тем, что вам интереснее – системное или прикладное программирование, операционные системы или базы данных, Интернеттехнологии или компьютерная графика. Вам необходимо как можно скорее наращивать вашу квалификацию. Имеет смысл выйти за рамки стандартной образовательной программы и самостоятельно познакомиться с какойто новой технологией или глубоко изучить какую-либо традиционную технологию, например, Remote Procedure Calls в операционной системе UNIX. В этом случае итогом вашей работы может стать не только новая программная разработка, но также и отчет или даже методическое руководство по изучению данного вопроса. Этим руководством впоследствии смогут воспользоваться ваши младшие товарищи, которые сейчас, может быть, только готовятся к поступлению в наш вуз. Конечно, такие нестандартные темы требуется более детально обсудить с преподавателем.

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

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

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

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

Приведем лишь несколько примеров:

– математика (конечно же, математика идет под номером один);

– физика (например, моделирование физических процессов в различных областях: оптика, гидравлика, электричество и т. д.);

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

– прогнозирование будущего в социально-экономической сфере (тут не обойтись без математики);

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

– демография (моделирование процессов изменения численности населения в глобальном и локальном масштабе);

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

3. Объем и уровень ваших знаний в настоящий момент времени.

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

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

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

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

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

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

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

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

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

Конечно, первоисточником технической информации является техническая документация. К ней, в частности, относятся:

– описания новых информационных технологий, предоставляемые их разработчиками на своих сайтах в открытом доступе (например, описание языка XML на сайте www.w3.org);

– описания программных продуктов, поставляемые в составе дистрибутивного комплекта;

– различные стандарты, например, те, которые регламентируют работу CGI-скриптов (множество стандартов, касающихся различных Webтехнологий, можно найти на сайте www.ietf.org);

– исходные тексты свободно распространяемых программных продуктов с открытым исходным кодом (например, на сайте sourceforge.net).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Перейдя от высокой литературы к нашим технологиям, приведем пример. Пусть темой вашего проекта будет файловый менеджер (коих уже написано великое множество). Тема вполне понятная. Можно даже оставить эту формулировку в качестве названия – файловый менеджер. Однако если посмотреть на существующие программы этого класса, то все они имеют какое-то другое название: Norton Commander, Demos Commander, Midnight Commander и т. д. На основе одного только такого названия невозможно сказать что-то определенное о назначении этих программ. Конечно, сейчас мы все прекрасно знаем это назначение. Но если бы это были совершенно неизвестные программы, то «вычислить» их назначение на основе только названия было бы весьма трудно.

Можно предложить компромиссный вариант, например: файловый менеджер «Русский Навигатор». В таком комплексном названии отражен как вид программы, так и ее фирменное название. На наш взгляд, для курсового проекта это тоже не самый лучший вариант. Кто знает вашу программу? Кто ей пользуется? Скорее всего, несколько человек, включая вас.

Но если вы выбираете для своего курсового проекта такое вот «рыночное»

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

Технология программирования Курсовой проект на тему: файловый менеджер «Русский Навигатор»

О чем скажет эта запись работнику кадровой службы при приеме вас на работу? Пожалуй, о вашем большом самомнении. Уж лучше тогда назвать работу бесхитростно: файловый менеджер. И все. Тем более что никто вам не запрещает в курсовом проекте написать просто – файловый менеджер, а распространяя вашу разработку в сети Интернет, назвать ее «Русский Навигатор». В случае если ваш «Русский Навигатор» будет иметь ошеломляющий успех у тысяч пользователей, вы сможете с гордостью сказать тому самому работнику кадровой службы, что это и есть ваш курсовой проект.

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

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

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

– отражать суть работы;

– соответствовать объему работы;

– быть благозвучным;

– быть кратким и емким;

– быть русскоязычным.

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

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

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

– учет наличия и продаж лекарств;

– прогнозирование потребности в лекарствах и планирование заказов лекарств;

– учет финансовых результатов деятельности аптеки;

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

Тогда возникает вопрос, что включает в себя термин «Аптека»: какую-то одну из перечисленных подсистем, две из них или все перечисленные подсистемы?

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

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

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

4. Apteka 1.0. Названия хуже, наверное, быть не может. Во-первых, из названия вообще не ясно назначение программного продукта и объем сделанной работы. Во-вторых, название написано на русском языке, но латинскими буквами. Что это дает для понимания сути работы? В-третьих, указан номер версии. Вряд ли номер версии целесообразно указывать в названии учебной работы. Что он показывает? Может быть, степень зрелости проекта? Представьте себе, что тема вашего проекта – «Apteka 4.0», а оценка, полученная вами – «удовлетворительно». Судя по номеру версии, продукт находится на весьма продвинутой стадии развития. Но судя по оценке, качество продукта все еще низкое. Если вам хочется показать, что вы являетесь продуктивным программистом, то вы можете все версии вашего программного продукта выложить на своем сайте в сети Интернет.

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

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

1. Титульный лист.

2. Содержание.

3. Введение.

4. Состав творческой группы.

5. План выполнения разработки.

6. Документ-концепция.

7. Архитектура и системные требования.

8. Технический проект.

9. Исходные тексты программ.

10. Методика тестирования.

11. Руководство пользователя.

12. Руководство программиста.

13. Заключение.

14. Список использованной литературы.

15. Приложения.

Общие требования к оформлению документации по курсовому проекту следующие.

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

2. Необходимо использовать шрифт Times New Roman или Arial, размер – от 10 до 14 пунктов. Номера страниц следует проставлять внизу листа посередине строки. Не следует использовать пестрые цветовые решения для представления текста: это технический документ, а не рекламный проспект.

3. Не следует включать в документацию пространные цитаты из учебников или материалы учебного характера из сети Интернет. Помните:

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

4. Документацию нужно представить в электронном виде в формате doc или pdf (кроме исходных текстов программ). При этом можно выбрать один из двух вариантов компоновки документации:

– все разделы документации включить в единый файл;

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

Данный раздел документации представлен в виде отдельного документа Concept.doc.

5. Исходные тексты программ нужно представить именно в том виде, в котором они используются для компиляции в системе программирования (например, тексты на языке C/C++) либо для запуска в операционной системе (например, тексты на языке Perl). Не нужно включать исходные тексты в документ формата doc или pdf.

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

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

Коснемся тезиса: «Программа должна быть как можно короче». Его часто используют студенты в качестве возражения в ответ на требование (его вы увидите далее по тексту) создать программу определенного объема, например, 2000 строк. В ответ можно сказать следующее:

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

Э. Синк, автор книги «Бизнес для программистов», пишет: «Один из моих излюбленных приемов – спрашивать, сколько строк кода написал человек за всю свою карьеру. Все отвечают по-разному. Одни говорят, что не имеют ни малейшего понятия. Другие говорят мне, что это дурацкий вопрос, и с жаром приводят все доводы, доказывающие, что умение программировать не исчисляется строками кода. Ну, хорошо, допустим. И все равно мне нравится этот вопрос. Я уверен, что хорошим программистом можно стать только в процессе написания кода. Чем больше, тем лучше.

Именно поэтому я хочу знать, сколько кода у вас за плечами».

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

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

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

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

Конкретные количественные требования к объему исходных текстов сформулирует преподаватель с учетом сложности вашей темы, выбранного языка программирования и других критериев. Мы же предлагаем ориентировочные требования. Объем исходного текста программы с комментариями (при коллективной работе – в расчете на одного участника творческой группы) должен составить не менее:

– 500 строк на оценку «удовлетворительно»;

– 1000 строк на оценку «хорошо»;

– 3000 строк на оценку «отлично».

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

Количество комментариев должно составлять 20–25 процентов от объема исходного текста, т. е. в среднем одна строка на 3–4 строки исходного текста.

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

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

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

– полное наименование высшего учебного заведения;

– наименование кафедры;

– тему курсового проекта;

– фамилию и инициалы студента, выполнившего проект (если работа коллективная, то приводятся сведения обо всех авторах работы);

– фамилию и инициалы преподавателя, принявшего работу;

– город и год разработки.

В Приложении 6 приведен пример оформления титульного листа.

3.3. Содержание Содержание – это также традиционный элемент текста пояснительной записки любого курсового проекта. В состав документации входят как относительно небольшие разделы, так и весьма объемные. Например, раздел «Документ-концепция» состоит из большого числа подразделов и имеет многоуровневую структуру. В содержании этот раздел нужно представить только одной строкой, без деталировки по всем его подразделам, например:

Раздел «Архитектура и системные требования» организован аналогично. Его в содержании также нужно представить только одной строкой, без деталировки по всем его подразделам.

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

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

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

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

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

Вспомните о ваших перспективных планах, которые мы обсуждали в разделе, посвященном выбору темы. Целью вашего курсового проекта может быть, например, следующее: создать технологическую базу для разработки программного продукта «А», использование которого в сфере «Б»

позволит повысить эффективность выполнения операций типа «В».

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

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

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

1. Изучить основные конструкции языков программирования Perl и JavaScript, познакомиться с основными возможностями системы управления базами данных PostgreSQL, познакомиться с технологией Ajax.

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

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

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

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

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

– архитектор;

– администратор;

– ведущий программист;

– программист;

– ответственный за тестирование;

– ответственный за документацию.

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

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

План строится по принципу «что – кто – когда». В нем отражаются следующие сведения:

– вид выполняемой работы;

– фамилия, имя и отчество разработчика, ответственного за ее выполнение (если ответственных несколько, то нужно указать их всех);

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

3.7. Документ-концепция В разных авторитетных источниках предлагаются различные названия документа, создаваемого на первом этапе разработки программного продукта. В книге Д. Леффингуэлла «Принципы работы с требованиями к программному обеспечению» предлагается название «документконцепция». В книге И. Соммервилла «Инженерия программного обеспечения» предлагается название «пользовательские требования». Отечественные ГОСТы рекомендуют называть такой документ «техническим заданием».

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

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

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

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

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

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

«нет требований, т. к. …».

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

В конце документа размещены справочные разделы: глоссарий и список сокращений.

3.8. Архитектура и системные требования Пример такого документа приводится в Приложении 2. На этапе архитектурного проектирования определяются самые общие черты устройства будущего программного продукта. Кроме собственно архитектуры, в документе содержатся и системные требования.

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

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

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

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

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

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

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

– пояснения по программной реализации модулей на данном шаге разработки;

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

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

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

3.10. Исходные тексты программ Сначала поговорим об оформлении исходных текстов ваших программ, а затем – о том, что нужно отразить в этом разделе документации.

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

С этой целью рекомендуется разработать свой собственный стандарт кодирования или воспользоваться одним из известных стандартов. Одним из примеров является стандарт GNU (www.gnu.org/prep/standards/). В среде операционной системы FreeBSD можно также увидеть аналогичный документ, введя команду man style Если вы используете заимствованный стандарт кодирования, то нужно отразить это в п. 6.2.3 «Документа-концепции» («Требования к стандартам»). Если вами разработан свой собственный стандарт кодирования, то нужно включить его в документацию в качестве приложения (и отразить это в содержании). В Приложении 4 приведен пример стандарта кодирования для языка Perl.

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

1. В каждом программном файле (модуле) должен содержаться заголовок (в виде комментария), в котором отражается следующая информация:

– название программы;

– название модуля (не имя файла, например, cities.pl, а название, отражающее назначение модуля, например, «Справочник городов»);

– дата разработки модуля;

– номер версии модуля (или программы в целом).

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

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

3. Ширина текста (или длина строки) не должна превышать ширину экрана, т. е. 80 символов.

4. Структурные отступы, с помощью которых выделяются вложенные управляющие конструкции while, if, for, должны аккуратно соблюдаться в едином стиле на протяжении всей программы. Если вы выбрали величину такого отступа равной, например, двум символам, то следуйте этой схеме постоянно.

Теперь о документации. В разделе «Исходные тексты программ» вы должны представить следующие сведения:

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

– перечень всех пар (или групп) взаимодействующих модулей с указанием типа сцепления между ними;

– меры Холстеда для каждого программного модуля;

– общий объем исходных текстов (число строк программного кода);

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

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

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

Для тестирования методом белого ящика нужно выбрать 2–3 процедуры (модуля), являющиеся наиболее важными для правильного функционирования программы.

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

Важное требование к методике тестирования – повторяемость (воспроизводимость) всех тестов при защите курсового проекта.

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

– порядок запуска программы;

– порядок использования функций программы (можно привести снимки экранных форм);

– описания возможных проблем и способов их решения;

– перечень сообщений, выводимых программой, и способов реагирования на них.

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

3.13. Руководство программиста В данном руководстве необходимо отразить следующие вопросы:

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

– порядок компиляции (если этап компиляции необходим) и установки программы;

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

– необходимые настройки операционной среды и самого программного продукта.

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

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

Можно оформить отдельное руководство по инсталляции в виде текстового файла с именем, например, INSTALL. Целесообразность такого шага обосновывается тем, что не все программные продукты требуют для своего функционирования наличия графической среды, но для прочтения файлов форматов doc или pdf наличие такой среды требуется. Таким образом, может случиться так, что пользователь будет вынужден устанавливать графическую среду только ради того, чтобы прочесть инструкцию по установке программного продукта. Вряд ли стоит так утруждать пользователя.

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

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

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

Подтверждением решения первой задачи будет фактическое написание исходных текстов ваших программ на языках программирования Perl и JavaScript с использованием технологии Ajax. Кроме того, вы использовали и СУБД PostgreSQL для управления вашими данными. Вы можете написать кратко о том, что в языке программирования вам понравилось, что не понравилось, что вызвало наибольшие трудности при его изучении и использовании.

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

В рамках этого анализа вы сравнивали функциональные возможности программ. Результаты анализа следовало отразить в «Документе-концепции»

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

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

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

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

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

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

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

Возможно, вы разместили свою разработку в сети Интернет.

Теперь вы можете заявить о степени достижения поставленной цели.

Цель может быть достигнута полностью, а может – и частично.

На этом ваше повествование может быть завершено.

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

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

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

ГОСТ 7.1–2003. Библиографическая запись. Библиографическое описание. Общие требования и правила составления.

ГОСТ 7.80–2000. Библиографическая запись. Заголовок. Общие требования и правила составления.

ГОСТ 7.82–2001. Библиографическая запись. Библиографическое описание электронных ресурсов. Общие требования и правила составления.

Эти стандарты представляют собой весьма пространные документы, особенно ГОСТ 7.1–2003. Однако для их практического использования можно ограничиться изучением только примеров, приведенных в заключительной части каждого из этих документов.

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

1. Соммервилл, И. Инженерия программного обеспечения [Текст] / Иан Соммервилл ; пер. с англ. А. А. Минько [и др.] ; под ред. А. А. Минько. – 6-е изд. – М. ; СПб. ; Киев : Вильямс, 2002. – 624 с. : ил. – Библиогр.:

с. 603–617 (352, 35 назв.). – Предм. указ.: с. 618–623. – Парал. тит. англ. – Перевод изд.: Software engineering / Ian Sommerville. 6th ed. London [etc.] :

Pearson Education, 2001. – 3500 экз. – ISBN 5-8459-0330-0 (рус.). – ISBN 0X (англ.).

2. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход [Текст] / Дин Леффингуэлл, Дон Уидриг ; пер. с англ. и ред. Н. А. Ореховой. – М. : Вильямс, 2002. – 446, [2] с. : ил. – Парал. тит. англ. – Прилож.: с. 369–438. – Библиогр.: с.

439–440. – Предм. указ.: с. 441–445. – Перевод изд.: Leffingwell, Dean.

Managing Software Requirements. A Unified Approach / Dean Leffingwell, Don Widrig. Boston : Addison-Wesley, [2000]. – 3500 экз. – ISBN 5-8459рус.). – ISBN 0-2016-1593-2 (англ.).

3. Российская государственная библиотека [Электронный ресурс] / Центр информ. технологий РГБ ; ред. Власенко Т. В. ; Web-мастер Козлова Н. В. – Электрон. дан. – М. : Рос. гос. б-ка, 1997–. – Режим доступа:

http://www.rsl.ru, свободный. – Загл. с экрана. – Яз. рус., англ.

Обратите внимание на ряд особенностей оформления библиографических описаний. Согласно ГОСТ 7.1–2003, все описание состоит из так называемых областей, а области – из элементов. Знаки препинания, которые используются для разделения этих областей и элементов, называются предписанными. Каждой области описания, кроме первой, предшествует знак точка и тире, который ставится перед первым элементом области. Обратите внимание, что используется именно тире, а не дефис. Вообще, нужно внимательно относиться к выбору между тире и дефисом в ряде ситуаций. Например, при указании диапазона страниц, на которых размещен какой-либо справочный материал, содержащийся в книге, используется тире, а для разделения групп цифр в стандартном номере ISBN используются дефисы.

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

Чтобы лучше понять правила расстановки пробелов в библиографическом описании, можно открыть текст ГОСТ 7.1–2003 в редакторе Microsoft Word и включить режим отображения служебных символов. При просмотре файла в этом режиме пробелы будут представлены в виде точек.

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

1. Соммервилл, И. Инженерия программного обеспечения [Текст] :

пер. с англ. / Иан Соммервилл. – 6-е изд. – М. ; СПб. ; Киев : Вильямс, 2002. – 624 с. : ил. – ISBN 5-8459-0330-0.

2. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход [Текст] : пер. с англ. / Дин Леффингуэлл, Дон Уидриг. – М. : Вильямс, 2002. – 446, [2] с. : ил. – ISBN 5-8459-0275-4.

3. Российская государственная библиотека [Электронный ресурс] / Центр информ. технологий РГБ ; ред. Власенко Т. В. ; Web-мастер Козлова Н. В. – Электрон. дан. – М. : Рос. гос. б-ка, 1997–. – Режим доступа:

http://www.rsl.ru, свободный.

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

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

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

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

Желаем вам, уважаемый читатель, проектировать и программировать с удовольствием!

1. Брайант, Р. Компьютерные системы: архитектура и программирование [Текст] : пер. с англ. / Р. Брайант, Д. О’Халларон. – СПб. : БХВПетербург, 2005. – 1104 с.

2. Браун, М. Perl. Архив программ [Текст] : пер. с англ. / М. Браун. – М. : БИНОМ, 2001. – 720 с.

3. Канер, С. Тестирование программного обеспечения [Текст] : пер. с англ. / Сэм Канер, Джек Фолк, Енг Кек Нгуен. – Киев : ДиаСофт, 2000. – 544 с.

4. Керниган, Б. Практика программирования [Текст] : пер. с англ. / Б.

Керниган, Р. Пайк. – СПб. : Невский диалект, 2001. – 381 с.

5. Кристиансен, Т. Perl: библиотека программиста [Текст] : пер. с англ. / Т. Кристиансен, Н. Торкингтон. – СПб. : Питер, 2001. – 736 с.

6. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход [Текст] : пер. с англ. / Дин Леффингуэлл, Дон Уидриг. – М. : Вильямс, 2002. – 446, [2] с.

7. Митчелл, М. Программирование для Linux. Профессиональный подход [Текст] : пер. с англ. / М. Митчелл, Дж. Оулдем, А. Самьюэл. – М. :

Вильямс, 2002. – 288 с.

8. Реймонд, Э. Искусство программирования для Unix [Текст] : пер. с англ. / Э. Реймонд. – М. : Вильямс, 2005. – 544 с.

9. Рочкинд, М. Программирование для UNIX [Текст] : пер. с англ. / М. Рочкинд. – М. : Русская редакция ; СПб. : БХВ-Петербург, 2005. – 704 с.

10. Синк, Э. Бизнес для программистов. Как начать свое дело [Текст] : пер. с англ. / Э. Синк. – СПб. : Питер, 2008. – 256 с.

11. Снейдер, Й. Эффективное программирование TCP/IP. Библиотека программиста [Текст] : пер. с англ. / Й. Снейдер. – СПб. : Питер, 2001. – 320 с.

12. Соммервилл, И. Инженерия программного обеспечения [Текст] :

пер. с англ. / Иан Соммервилл. – 6-е изд. – М. ; СПб. ; Киев : Вильямс, 2002. – 624 с.

13. Тейнсли, Д. Linux и UNIX:программирование в shell. Руководство разработчика [Текст] : пер. с англ. / Д. Тейнсли. – Киев : BHV, 2001. – 464 с.

14. Харт, Дж. Системное программирование в среде Windows [Текст] : пер. с англ. / Дж. Харт. – М. : Вильямс, 2005. – 592 с.

15. Эбен, М. FreeBSD. Энциклопедия пользователя [Текст] : пер. с англ. / Майкл Эбен, Брайан Таймэн. – Киев : ДиаСофт, 2002. – 736 с.

Приложение 1. Документ-концепция История исправлений и дополнений 01.04.2005 0. Проведены реструктуризация и дополне- Е. П. Моргунов 20.06.2009 1. и Д. Леффингуэлла (их библиографические описания см. ниже) Примечание. Дата выпуска версии 0.5 – приблизительная.

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

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

Программный продукт в технологическом плане будет представлять собой информационную систему, построенную на основе «большой» СУБД и Web-технологий.

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

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

– хранилище цитат из проработанных источников;

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

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

Использование программного продукта позволит:

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

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

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

– повысить уровень культуры в работе с библиографической информацией.

Сферы применения программного продукта:

– индивидуальное использование;

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

1.3. Ссылки и использованная литература 1.3.1. Список документов, упоминаемых в документе-концепции 1. Архитектура и системные требования (спецификация).

1.3.2. Список источников, к которым можно обратиться за справками в процессе разработки – ГОСТ 7.1–2003 «СИБИД. Библиографическая запись. Библиографическое описание. Общие требования и правила составления»;

– ГОСТ 7.11–2004 «СИБИД. Библиографическая запись. Сокращение слов и словосочетаний на иностранных европейских языках»;

– ГОСТ 7.12–93 «СИБИД. Библиографическая запись. Сокращение слов на русском языке. Общие требования и правила»;

– ГОСТ 7.60–90 «СИБИД. Издания. Основные виды. Термины и определения»;

– ГОСТ 7.80–2000 «СИБИД. Библиографическая запись. Заголовок. Общие требования и правила составления»;

– ГОСТ 7.82–2001 «СИБИД. Библиографическая запись. Библиографическое описание электронных ресурсов. Общие требования и правила составления»;

– ОСТ 29.130-97 «Издания. Термины и определения».

2. Система автоматизации библиотек ИРБИС. Общее описание системы [Текст].

– М. : ГПНТБ России, 2002. – 260 с.

1.3.3. Список использованной литературы 1. Соммервилл, И. Инженерия программного обеспечения [Текст] / Иан Соммервилл ; пер. с англ. А. А. Минько [и др.] ; под ред. А. А. Минько. – 6-е изд. – М. ;

СПб. ; Киев : Вильямс, 2002. – 624 с. : ил. – Библиогр.: с. 603–617 (352, 35 назв.). – Предм. указ.: с. 618–623. – Парал. тит. англ. – Перевод изд.: Software engineering / Ian Sommerville. 6th ed. London [etc.] : Pearson Education, 2001. – 3500 экз. – ISBN 5-8459рус.). – ISBN 0-201-39815-X (англ.).

2. Леффингуэлл, Д. Принципы работы с требованиями к программному обеспечению. Унифицированный подход [Текст] / Дин Леффингуэлл, Дон Уидриг ; пер. с англ. и ред. Н. А. Ореховой. – М. : Вильямс, 2002. – 446, [2] с. : ил. – Парал. тит. англ. – Прилож.: с. 369–438. – Библиогр.: с. 439–440. – Предм. указ.: с. 441–445. – Перевод изд.: Leffingwell, Dean. Managing Software Requirements. A Unified Approach / Dean Leffingwell, Don Widrig. Boston : Addison-Wesley, [2000]. – 3500 экз. – ISBN 5-8459-0275- (рус.). – ISBN 0-2016-1593-2 (англ.).

2. Описание пользователей 2.1. Виды пользователей и их краткие описания 2.1.1. Ученый Имеет высокий уровень культуры интеллектуального труда. Читает много разнообразной научной литературы, как периодической, так и непериодической. Пишет научные статьи, доклады для выступления на конференциях и учебно-методические работы.

2.1.2. Аспирант Стремится стать ученым и старается делать то же, что описано в п. 2.1.1.

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

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

2.2. Среда пользователя Большинство пользователей используют операционную систему (ОС) Windows, хотя в настоящее время все большую популярность набирает ОС Linux, относящаяся к классу UNIX-подобных ОС.

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

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

2.3.2. Аспирант То же, что и для ученого.

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

2.3.4. «Обычный» человек Необходим инструмент, который мог бы помочь в упорядочивании домашней библиотеки, фонотеки, видеотеки.

3. Состояние рынка и конкурирующие продукты 3.1. Характеристика рынка На исследуемом рынке представлены два типа программных продуктов:

– «большие» профессиональные автоматизированные библиотечные информационные системы (АБИС), такие, как «ИРБИС», «Академия+» и др., предназначенные для использования в библиотеках;

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

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

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

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

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

Основные технологии, применяемые в отрасли для разработки подобных программных продуктов, следующие: языки программирования – Delphi, C/C++, Visual Basic; СУБД – CDS/ISIS (ЮНЕСКО), Microsoft Access и др. «Малые» информационные системы не работают под управлением операционной системы UNIX (Linux, FreeBSD).

3.2. Конкурирующие программные продукты 3.2.1. Общая характеристика К недостаткам существующих «больших» библиотечных информационных систем (при оценке их с позиции индивидуального использования в домашних условиях) можно отнести следующее:

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

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

– высокая цена программного продукта;

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

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

К недостаткам существующих «малых» информационных систем можно отнести следующее:

– отсутствие возможности формирования библиографических описаний, соответствующих стандартам (ГОСТ 7.1–2003 или аналогичному международному стандарту). Вместо цельного библиографического описания имеется только набор сведений об объектах, внесенных в базу данных: авторы, заглавие, место издания и т. д. В отчетах эти сведения группируются в некое подобие описания, но оно не соответствует никаким стандартам;

– отсутствие развитой возможности конфигурирования программного продукта (с использованием конфигурационного файла или базы данных). Конфигурирование сводится, в основном, к настройке внешнего представления программы и данных, но оно мало помогает в ускорении работы оператора при вводе данных;

– неразвитость системы вспомогательных средств, сокращающих объем работы пользователя при вводе однотипных данных (подобные средства есть во всех Internetбраузерах);

3.2.2. Система автоматизации библиотек «ИРБИС»

Разработчик: Государственная публичная научно-техническая библиотека России (ГПНТБ). Сайты: http://www.gpntb.ru, http://www.elnit.org.

«Большая» библиотечная информационная система. Очень мощная, сложная, дорогая.

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

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

– технология автоматического формирования словарей, на основе которых реализуется быстрый поиск по любым элементам описания и их сочетаниям;

– средства для ведения и использования Авторитетных файлов, баз данных УДК, ББК, ГРНТИ и Тезауруса;

– поддержка традиционных «бумажных» технологий: от печати форм заказа/подписки и листов книги суммарного учета до печати всех видов каталожных карточек;

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

– поддержка многоязычия на основе UNICODE, т. е. возможность ввода на любых языках мира;

– поддержка ссылок от библиографических описаний на полные тексты, графические данные и другие внешние объекты (включая ресурсы Интернет);

– средства для создания и ведения полнотекстовых баз данных (электронной библиотеки);

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

– средства для перевода пользовательских интерфейсов на другие языки;

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

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

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

«Оригинальное программное обеспечение системы написано на Delphi с использованием библиотеки ISIS32.DLL (Bireme, Бразилия). Физическая структура БД соответствует СУБД CDS/ISIS (ЮНЕСКО)» (цитата из описания программного продукта).

3.2.3. Автоматизированная библиотечная информационная система «Академия+»

Разработчик: Центр автоматизированных технологий «Ростехноком». Сайты:

http://www.rostechnocom.ru; http://www.academy-plus.ru.

«Большая» библиотечная информационная система. Очень мощная, сложная, дорогая.

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

– масштабируемая трехуровневая клиент-серверная архитектура;

– независимость от программно-аппаратной платформы (любая аппаратная платформа: IBM PC, SUN и др.; любая операционная система: Windows, UNIX, LINUX);

– независимость от СУБД (любая реляционная СУБД: ORACLE, MS SQL Server, My SQL, PostgresSQL и др.);

– работа системы в Internet и Intranet без ограничения количества пользователей;

– поддержка UNICODE и штрих-кодирования на программном уровне.

3.2.4. BookCAT Разработчик: FNProgramvare (Норвегия). Сайт: http://www.fnprg.com.

«Малая» информационная система. Самая развитая из систем подобного класса.

3.2.5. Учет книг http://www.prostoysoft.ru.

Фрагмент описания программного продукта, взятый с сайта разработчика (стиль и орфография сохранены) Основные функции программы Ведение базы книг, журналов. Каталогизация В базе данных содержится информация о книгах, журналах. Предусмотрены такие поля как – название, авторы, категория, тип, издательство, серия, формат, год издания, количество страниц, тираж, обложка, ISBN, УДК, № шкафа, № полки, блок, подблок, время добавления и т. д. Для каждой книги показываются все ее читатели (которые читали эту книгу ранее и читают сейчас).

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

Учет должников по возврату книг, журналов Система фиксирует информацию о читателях – ФИО, контактная информация, выданные книги, даты выдачи и возврата книг. Контролируя значение поля с датой возврата книги можно легко вести учет должников. Таблица «На руках» показывает список всех выданных на руки книг и журналов.

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

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

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

Удалять дублированные записи с одинаковым названием и автором. Можно настроить по-другому.

Сортировать таблицы по любому полю, включая сортировку по нескольким полям (до 3-х) удерживая клавишу Shift.

Фильтровать таблицу по любому полю, используя следующие операторы: =, >, >=, $module, create_condition => \&create_condition, Скобки допустимо расставлять и таким образом: