ДОКУМЕНТИРОВАНИЕ.docx

ДОКУМЕНТИРОВАНИЕ

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

– не менее важная тема в технологии разработки программного обеспечения.

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

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

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

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

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

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

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

Вопросы для самопроверки

1.  Какие существуют формы документации на программное обеспечение?

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

3.  Что важнее, программа или ее документация?