Реферат: Документирование программного обеспечения

Колледж Информатики и Вычислительной Техники

Факультет программирования

РЕФЕРАТ


Дисциплина: технология программирования.

Тема: документирование программного обеспечения.

Выполнил студент:  

Таллинн

2003

Содержание

1. Документированиепрограммного обеспечения.

1.1Техническое задание.

1.2Внешние и внутренние языки спецификации.

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

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

Документирование программного обеспечения

Когда программист-разработчик получает в той или инойформе задание на программирование, перед ним, перед руководителем проекта иперед всей проектной группой встают вопросы: что должно быть сделано, кромесобственно программы? что и как должно быть оформлено в виде документации? чтопередавать пользователям, а что — службе сопровождения? как управлять всем этимпроцессом? Кроме упомянутых вопросов есть и другие,например, что должно входить в само задание на программирование? Прошло многолет, программирование происходит в среде совершенно новых технологий, многиепрограммисты, работая в стиле drag-and-drop,могут годами не видеть текст своих программ. Это не значит, что исчезланеобходимость в их документировании. Более того, вопросы о наличии хоть какой-тосистемы, регламентирующей эту сторону создания программных средств, продолжаютзадавать постоянно. Спрашивают и о том, есть ли обязательные для применениястандарты (особенно остро стоит этот вопрос, когда разработка выполняется позаказу государственной организации или предприятия). Интересуются и тем, гдеможно купить имеющиеся стандарты.

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

Техническое задание

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

Техническое задание наразработку ПО должно включать следующие разделы:

введение;

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

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

В разделе “Введение”указывается наименование, краткая характеристика области применения ПО.

В разделе “Основания дляразработки” указывается:

 

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

В разделе Назначениеразработки должно быть указано функциональное и эксплуатационное назначение ПО.

Например,UML – как универсальный язык моделирования. Можетиспользоваться и для постановки технического задания.

Внешние и внутренние языки спецификации

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

 

Соглашение о требованиях;
Внешняя спецификация;
Внутренняя спецификация.

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

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

1.ОПИСАНИЕ ПРОГРАММНОГО ИЗДЕЛИЯ

1.1. Наименование и шифры ПО (полное наименование,сокращенные наименования, шифры ПО и проекта).

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

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

2.ЦЕЛИ

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

3.СТРАТЕГИЯ

3.1.Соглашения относительно представления материала.

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

3.1.2.Терминология (особенно специфическая для данного изделия).

3.1.3.Синтаксис (приводятся, если необходимо, синтаксические правила для дальнейшегоописания требований).

3.2.Генерируемое программное обеспечение (классифицируется как вспомогательное ипорождаемое описываемым изделием).

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

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

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

3.3.n.1.Внешние ограничения.

3.3.n.1.1.Стандарты (список используемых промышленных стандартов и собственных стандартовпредприятия).

3.3.n.1.2.Ограничения на совместимость. Необходимо рассматривать несколько аспектовсовместимости:

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

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

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

подобными изделиями (т.е. выполняющих похожие функции вдругих программных изделиях); конкурирующими изделиями (других организаций).

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

3.3.n.1.4.Аппаратные ограничения. Приводится перечень устройств, необходимых для работыПО (с указанием минимальной, оптимальной и максимальной конфигурации).Указываются все действующие ограничения на оборудование, например, физическиехарактеристики терминала или требование запрещения использования звуковогосигнального устройства.

3.3.n.2.Внешние характеристики.

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

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

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

3.3.n.2.3.Входы. Описание подобно п. 3.3.2.1

3.3.n.3.Эргономические характеристики.

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

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

защитаданных пользователя;

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

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

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

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

4.ИСПОЛЬЗУЕМЫЕ МАТЕРИАЛЫ (в т.ч. справочные)

5.ПЕРЕДАЧА ЗАКАЗЧИКУ И ВВОД В ДЕЙСТВИЕ

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

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

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

Всвязи с этим следует различать две категории пользователей: ординарныхпользователей программы и администраторов. Ординарный пользователь программы (end-user)использует программу для решения своих задач (в своей предметной области).Это может быть инженер, проектирующий техническое устройство, или кассир,продающий железнодорожные билеты с помощью данной программы. Он может и незнать многих деталей работы компьютера или принципов программирования.Администратор программны (system administrator)управляетиспользованием программы ординарными пользователями и осуществляетсопровождение программного средства, не связанное с модификацией программ.Например, он может регулировать права доступа к программе между ординарнымипользователями, поддерживать связь с поставщиками программы или выполнятьопределенные действия, чтобы поддерживать программу в рабочем состоянии, еслионо включено как часть в другую систему.

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

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

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

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

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

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

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

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

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

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

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

1. документация, определяющая строение программ иструктур данных ПС и технологию их разработки;

2.документацию, помогающую вносить изменения в программное средство.

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

Внешнееописание программного средства (Requirements document).

Описаниеархитектуры программного средства (description of the system architecture), включая внешнюю спецификацию каждой ее программы.

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

Длякаждого модуля — его спецификация и описание его строения (design description).

Текстымодулей на выбранном языке программирования (programsource code listings).

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

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

Документациявторой группы содержит

Руководствопо сопровождению программного средства (systemmaintenance guide), которое описывает известныепроблемы вместе с программным средством, описывает, какие части системыявляются аппаратно- и программно-зависимыми, и как развитие программногосредства принято в расчет в его строении (конструкции).

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

Вид эксплуатационного документа

Содержание эксплуатационного документа

Ведомость эксплуатационных документов Перечень эксплуатационных документов на программу. Формуляр Основные характеристики программы, комплектность и сведения об эксплуатации программы. Описание применения Сведения о назначении программы, области применения, классе решаемых задач, применяемых методах, ограничениях для применения, минимальной конфигурации технических средств. Руководство системного программиста Сведения для проверки, обеспечения функционирования и настройки программы на условия конкретного применения. Руководство программиста Сведения для эксплуатации программы. Руководство оператора Сведения, необходимые для осуществления действий, связанных с выполнением программы вычислительной системой. Описание языка Описание синтаксиса и семантики языка. Руководство по техническому обслуживанию Сведения для применения текстовых и диагностических программ при обслуживание технических средств. 1. www.ergeal.ru/archive/cs/tp/   — Технология программирования, конспект лекций ВМиК МГУ, кафедра системногопрограммирования

2.http://www.aanet.ru/~web_k46/textbooks/std_pro/face.htm- Богданов Д.В., Путилов В.А., Фильчаков В.В. Стандартизация процессов обеспечениякачества программного обеспечения. — Апатиты, КФ ПетрГУ, 1997.

 

еще рефераты
Еще работы по информатике, программированию