2.Процесс документирования
Процесс документирования должен быть выполнен в два этапа. Поэтапные работы не выполняются одновременно. На отдельных этапах работы могут проводиться параллельно.
Представление исходных материалов
Заказчик должен обеспечивать документатору доступ:
a) ко всем соответствующим спецификациям, форматам записей, компоновкам экранов и отчетов, выходным результатам работы средств автоматизации программирования (CASE tool) и другой информации, необходимой для подготовки документации;
b) к рабочей копии программного средства (при необходимости);
) к аналитикам и программистам, включая своевременное правильное решение вопросов, возникающих у персонала разработчиков документации;
) к типичным пользователям (по возможности) для анализа аудитории и тестирования на практичность.
В обязанности документатора входит обеспечение плодотворности контактов с разработчиками программных средств заказчика, гарантирующее как минимум понимание сути выпускаемой продукции и соответствующих ей аудиторий.
Примечание - Документатор не отвечает за разработку, проверку или корректировку исходных материалов, а только за их получение.
Независимо от того, является ли документатор одновременно разработчиком программного средства, заказчик должен обеспечить его копиями всех применяемых стандартов, руководствами по стилям и форматам, а также соответствующими материалами (если они не являются общедоступными). Документатор должен обеспечить данными материалами соответствующий персонал разработчиков документации.
Обязанностью разработчика является обеспечение полноты, правильности и актуальности всех материалов, предъявляемых разработчику на момент их поставки.
Разработчик должен гарантировать, что представление документатору данных материалов не нарушает прав интеллектуальной собственности любой третьей стороны.
Документатор должен предпринять соответствующие шаги по сохранению материалов, представленных заказчиком, обеспечить защиту информации о требованиях заказчика и возвратить все материалы заказчику по завершении проекта документирования.
В ряде случаев нет необходимости возвращать все материалы; данный вопрос должен быть оговорен в договоре. В ряде случаев требуется сохранить конфиденциальность и секретность предоставленных материалов. В договоре должны быть установлены уровни (грифы) конфиденциальности или секретности материалов, представляемых заказчиком документатору.
Лекция №18 Тема.8.5.Создание документации пользователя
3.План документирования
4.Контроль плана документирования
3.Документатор должен подготовить план документирования, в котором должны быть определены задания, выполняемые при создании конкретной документации. Данный план должен быть официально согласован заказчиком, что подтверждает полный учет в этом плане всех требований заказчика. Обычно план документирования должен охватывать весь комплект документации, например руководства пользователя, диалоговую документацию, справочные тексты и краткие справочные карты.
В плане документирования должны быть четко описаны область применения и ограничения по использованию планируемой документации, а также основные решения по анализу и проектированию этой документации. В плане также должны быть определены процессы и проверки, выполняемые при разработке документации.
План документирования должен охватывать следующие вопросы (но не ограничиваться ими):
a) рабочее наименование, назначение, область применения и ограничения по использованию планируемой документации;
b) спецификацию стиля в соответствии ;
c) определение аудитории пользователей ;
d) обоснование причин использования документации данной аудиторией и ее целевое назначение;
e) содержание (план-проспект) документации, с оценкой ее постраничного объема, и соответствующие уточнения для других машинных носителей документации;
f) номенклатуру поставки - число печатных копий, наличие электронных копий, форматы дисков и файлов (включая версии программных средств) и откуда они могут быть поставлены;
g) установление собственника авторских прав на документацию и любых других прав собственности.
Вопрос прав собственности является сложным. Во всех договорах на документацию должны быть указаны собственники соответствующих прав. При этом может быть указана последующая возможность передачи авторских прав от документатора к заказчику. Передача авторских прав целесообразна при определении места и способа тиражирования документации;
h) обеспечение перевода документации на другие языки.
i) уровни (грифы) секретности и конфиденциальности (при необходимости);
) процедуры и проверки, могущие влиять на процесс разработки документации, включая, при необходимости, хранение, поиск, резервирование, передачу и оценку качества;
k) методы и средства производства (тиражирования) и используемые версии данных средств;
Конкретные лица привлекаются на различных этапах написания и производства (тиражирования) документации в зависимости от уровня своего опыта и знаний. Например, может быть необходимым хорошее знание автором документируемой системы и опыт в написании документации; для редактора может потребоваться только опыт редактирования, но не знание системы; от компоновщика (оформителя) может не требоваться других знаний кроме знания средств оформления;
m) взаимосвязи (подчиненности) проекта;
n) почасовую загрузку и зарплату персонала (руководство по оценке этих факторов приведено в приложении F);
o) требования к проектным ресурсам, включая информационные и прочие ресурсы, представляемые заказчиком, и срокам их представления;
р) метод передачи документатору информации об изменениях программного средства в процессе его разработки;
q) планы контроля изменений и сопровождения документации (факультативно);
r) планы проверки документации после ее создания;
s) календарное планирование (графики) по контрольным точкам , включая (при необходимости):
1) утверждение плана документирования,
2) подготовку, проверку и корректировку проекта каждого документа,
3) тестирование на практичность,
4) подготовку оригиналов фотошаблонов,
5) распечатку, переплетение и распространение документации.
При необходимости каждый из пунктов плана должен быть описан для каждого элемента документации.
4.Контроль плана документирования
После официального согласования плана документатор должен нести ответственность за контроль и распространение данного плана. Документатором должен быть составлен список по распространению учтенных копий данного плана.
В случае внесения в план последующих изменений (согласованных документатором и заказчиком) документатор должен гарантировать получение этих изменений всеми держателями учтенных копий.
Вследствие проблем, возникающих при наличии устарелых копий плана, документатор должен запретить его несанкционированное копирование и предусмотреть процедуры аудита всех обновляемых копий плана.
Лекция №19 Тема.8.5.Создание документации пользователя
5.Проверка плана документирования
6.Тестирование документации на практичность
5.Проверка плана документирования должна гарантировать, что документация, предусмотренная планом документирования, после его выполнения будет удовлетворять целям заказчика. При утверждении плана документирования заказчик согласовывает все характеристики номенклатуры поставки, предусмотренной планом.
Заказчики должны уделять особое внимание структуре, полноте и практичности документации в соответствии с планом-проспектом ее содержания. План документирования должен быть проверен и утвержден (согласован) до начала работ над первым проектом документации.
Первая редакция (проект) должна содержать основную часть документации в соответствии с планом документирования, а также содержание, приложения и словарь (словник, определения). При применении средств автоматического создания указателя каждая его предметная рубрика (индекс) должна ссылаться на конкретные пункты документации. Орфография, пунктуация, стиль и компоновка документации должны соответствовать указанным в плане документирования.
Первый проект документации должен быть проверен заказчиком. Данная проверка предназначена для контроля технической правильности и полноты документации и должна гарантировать соответствие данного проекта заданиям плана документирования. Также проверяют соответствие орфографии, пунктуации, стиля и компоновки документации требованиям плана документирования.
При утверждении первого проекта заказчик согласовывает техническую правильность, структуру, понятность и полноту документации, исключая предложенные изменения. Перед предъявлением заказчику первый проект должен быть отредактирован по следующим причинам:
a) чтобы проверяющий не отвлекался на корректировку типографских и компоновочных ошибок;
b) чтобы любые технические неточности, внесенные при редактировании, были обнаружены проверяющим.
Проект должен быть проверен на соответствие выданным заданиям, указанной аудитории, содержанию и другим характеристикам, согласованным в плане документирования. Перед возвратом первого проекта с комментариями документатору заказчик должен быть уверен, что проект, включая все корректировки, соответствует плану документирования.
Во второй проект документации должны быть включены все изменения, согласованные с заказчиком при проверке первого проекта, а комплектность поставки второго проекта по возможности должна соответствовать номенклатуре поставки, оговоренной в плане документирования.
Данная проверка предназначена для контроля правильности внесения в документацию всех изменений, указанных заказчиком на этапе первого проекта.
При утверждении второго проекта заказчик согласовывает все аспекты документации за исключением физической формы представления документации по данному проекту, которая может не соответствовать указанной в номенклатуре поставки.
При утверждении второго проекта заказчик должен быть уверен, что по данному проекту (включая внесенные изменения по результатам проверки первого проекта) могут быть изготовлены гранки.
6.Тестирование документации на практичность
В плане документирования должен быть указан требуемый уровень тестирования документации на практичность.
Минимально должно быть проведено одно тестирование на практичность документации, используемой для выпускаемой версии программного средства.
Тестирование на практичность следует рассматривать как дополнения к проводимым проверкам и анализам документации. Подобное тестирование при разработке должно проводиться на прототипе документации, наиболее полно моделирующем ее окончательную версию.
При установлении условий данного тестирования должен быть полностью указан стандарт на характеристики практичности, по которому проводят измерение. Следует также определить соответствующий(е) метод(ы) измерения и процесс описания результатов замеров.
При необходимости в плане документирования следует определить среду тестирования, которая должна полностью соответствовать эксплуатационной среде конечного пользователя.
Тестирование на практичность может быть использовано для оценки (измерения) практичности по ГОСТ Р ИСО/МЭК 12119.
Лекция №20 Тема.8.5.Создание документации пользователя
7 Контроль изменений и сопровождение документации
8.Содержание спецификации стиля. Стиль описания
В плане документирования должны быть предусмотрены следующие четыре типа изменений документации:
a) функциональные изменения данной версии - изменения функции программного средства, внесенные при разработке документации и отраженные в опубликованной документации;
b) функциональные изменения последующей версии - изменения функции программного средства, внесенные при разработке документации и не отраженные в опубликованной документации, но подлежащие учету в последующей редакции документации.
c) изменения программного средства после публикации - изменения конкретных функций программного средства после издания данной документации;
d) изменения документа после публикации - изменения в опубликованной документации, обусловленные изменениями программного средства или обнаружением погрешностей в данной документации.
Документатор должен обеспечить проектирование документации так, чтобы допустить внесение в нее изменений всех четырех типов. Для этого необходимо, чтобы:
a) была предусмотрена процедура внесения каждого типа изменений в документ.
Разработчики документации обычно должны получать учтенные копии изменений программного средства, подтверждающие внесение соответствующих изменений в данное средство после конкретной даты его пересмотра;
b) наименование документа и номер версии или дата были указаны в верхнем или нижнем колонтитуле конкретного документа;
c) в бумажном документе с замененными страницами была предусмотрена таблица действующих страниц (лист изменений) или нечто подобное, позволяющее пользователю контролировать наличие каждой страницы документа;
d) дополнительно были предусмотрены методы, обеспечивающие внесение изменений в каждую учтенную копию конкретного документа;
e) дополнительно был предусмотрен метод, позволяющий пользователю контролировать соответствие конкретной копии данного документа используемой версии программного средства.
В договоре должно быть оговорено, что изменения каждого типа вносятся в документацию документатором.
8. Содержание спецификации стиля
Должен быть указан язык, на котором составлена документация для конкретной страны, например французский (для Канады).
При необходимости для принятого языка должен быть указан соответствующий орфографический словарь и, по возможности, список исключений из него.
Должен быть определен национальный орфографический словарь, удовлетворяющий интересам основной аудитории пользователей в данной стране. По возможности словарь следует представить в виде файла орфографического контроля.
Должны быть приведены рекомендации по грамматике языка и стилю ее применения.
Должен быть определен стандарт по национальной грамматике и ее применению в интересах основной аудитории пользователей в данной стране.
Лекция №21 Тема.8.5.Создание документации пользователя
9. Бумажная документация
Должен быть определен используемый размер бумаги. При выборе размера бумаги должно быть учтено следующее:
а) форматы А4, А5 и В5 указаны в настоящем стандарте
b) как будут храниться данные документы (в некоторых архивах возникают проблемы с хранением документов в конкретных форматах);
c) используются ли распечатки экранов (распечатки целых экранов в формате А5 недостаточно разборчивы);
d) используемый национальный стандартный формат бумаги, если документация представляется в виде фотокопий;
e) требования к мобильности и рабочей области документации.
Должна быть определена ориентация конкретной страницы документа как книжная (вертикальная) или альбомная (горизонтальная). При необходимости для языков, допускающих варианты ориентации текста, следует ее указать (например, сверху вниз, справа налево, на развороте или обороте по отношению к крышке переплета).
Следует указать, будет ли документация печататься в одно- или двустороннем формате. Двусторонний формат следует применять при печатном способе выпуска исходного материала, так как при этом расходуется меньше бумаги. Двусторонний формат можно использовать при выпуске фотокопий исходного материала. Односторонний формат может быть выбран из-за соображений практичности документации.
Должна быть определена минимально допустимая разрешающая способность печати (количество точек в 1 дюйме/1 мм). Минимально рекомендуемой является разрешающая способность 300 точек/дюйм. Должно быть определено расстояние от полосы набора до корешка переплета.
Должны быть определены расстояния от полосы набора до внешних краев страницы. Должны быть определены цвета красок, используемых при печати.
Должны быть определены цвет, масса и качество (номер) бумаги, используемой для документации.
Если в документации применяются разделители, должны быть указаны их цвет, масса и качество. В спецификации стиля должна быть определена информация, печатаемая на разделителях, а также их формат, ориентация и используемый шрифт.
Должен быть указан метод тиражирования документации (печатный, фотокопировальный и т.д.), а также соответствующие ему показатели качества. Должен быть указан метод переплетения документации. Должна быть определена схема нумерации страниц. Каждая страница должна иметь индивидуальный номер. Номера страниц должны быть проставлены в порядке их брошюрования.
При брошюровке документа с заменяемыми страницами схема нумерации должна учитывать номер текущей главы (раздела) с номером страницы в данной главе (разделе), например «1-1», «1-2» и т.д. (тем самым обеспечивается вставка страниц в документ без перенумерации всех последующих страниц).
В случае брошюровки документа без замены страниц используют порядковую нумерацию, например «1», «2» и т.д. Иногда для нумерации страниц содержания используют другую схему («i», «ii» и т.д.). Следует избегать схожих методов нумерации страниц вспомогательного (указателя и т.д.) и вводного материалов, так как это может привести к неоднозначности в случае изъятия или вставки страниц.
Должны быть определены схемы нумерации рисунков и таблиц (при необходимости их нумерации).
Должны быть указаны возможности применения сносок или концевых примечаний. В документации пользователя программного средства данные элементы обычно не используют; в спецификации стиля следует запретить их применение. Должны быть определены правила пагинации (постраничного разбиения, например, чтобы заголовки не проставлялись в конце страницы) и плотности документа (например, регулирование количества чистых страниц, начальных и концевых висячих строк).
Должны быть определены виды вводных и вспомогательных материалов, включая (при необходимости) требования к содержанию и оформлению:
a) титульного листа;
b) информации о гарантиях, авторских правах, компенсациях и торговой марке;
c) содержания;
d) списка рисунков и таблиц;
e) приложений;
f) словаря (глоссария);
g) перечней обозначений и сокращений;
h) указателя.
Должен быть определен порядок расположения данных элементов в документе.
Должны быть определены гарнитуры и кегли шрифтов, используемых в основной части документа.
Должно быть указано число колонок, используемых при оформлении страниц документа. Наиболее часто в документации пользователя программного средства используют одноколонное оформление страниц, но может быть также использовано двухколонное оформление.
Для текста основной части издания должны быть определены отступы (втяжки) слева или справа от края набора основного для издания формата, когда часть строк полосы набирают на более узкий формат со сдвигом влево (правосторонняя втяжка), вправо (левосторонняя), с обеих сторон (двусторонняя), а также пробелы по вертикали (например, межстрочные, межабзацевые).
Должны быть определены параметры выравнивания текста основной части на выбранном языке (например, левостороннее или по ширине).
Должно быть определено количество уровней заголовков, а для каждого уровня задано его обозначение или нумерация.
Должен быть определен стиль текста заголовков для используемых в документации языков (например, «Стиль основных предложений», «Все буквы заглавные»).
Должны быть определены гарнитуры и кегли шрифтов, отступы по горизонтали и интервалы по вертикали для каждого уровня заголовков.
Должны быть определены графические элементы (например, подчеркивание, раскраска, пиктограммы), применяемые на каждом уровне заголовков.
Должно быть определено содержание заполнения верхних и нижних колонтитулов.
Должны быть определены гарнитуры и кегли шрифтов, а также горизонтальное и вертикальное расположение верхних и нижних колонтитулов. При двусторонней печати отдельно должно быть определено содержание и оформление верхних и нижних колонтитулов левых и правых страниц.
Должны быть определены графические элементы (например, подчеркивание, раскраска, пиктограммы), применяемые для колонтитула каждого типа.
Должно быть определено содержимое надписей.
Должны быть определены гарнитуры и кегли шрифтов, а также расположение надписей в документе. Должны быть определены правила оформления таблиц, например головки таблиц следует повторять при переходе на другую страницу. Должны быть определены гарнитуры и минимальные кегли шрифтов, используемых в таблицах.
Отчеты (сообщения) являются результатами работы прикладных программных средств, выдаваемые в печатном или экранном виде. Образцы отчетов обычно включают в документацию пользователя программного средства. Могут быть установлены правила оформления и содержания отчетов. Должны быть определены гарнитуры и минимальные кегли шрифтов, используемые в отчетах.
Должны быть также установлены правила использования в отчетах страниц-раскладок и страниц-разверток.
Должны быть установлены общие правила содержания распечаток экранов. Распечатки экранов лучше понимаются, когда на каждой из них отражены реальные данные. В распечатках также должны быть использованы функциональные данные.
Должны быть установлены общие правила оформления (компоновки) распечаток экранов.
Должны быть установлены, используемые в рисунках гарнитуры и кегли шрифтов, а также минимальная толщина линий. Должны быть установлены правила расположения (ориентации) рисунков.
Должен быть определен стиль текста уведомлений и предостережений для используемых в документации языков (например, «Стиль основных предложений», «Все буквы заглавные»).Должны быть определены гарнитуры и кегли шрифтов, отступы по горизонтали и интервалы по вертикали для уведомлений и предостережений.
Должны быть определены графические элементы (например, подчеркивание, раскраска, пиктограммы), используемые в уведомлениях и предостережениях.
Лекция №22 Тема.8.5.Создание документации пользователя
10. Электронная документация
В спецификации стиля документации могут быть указаны один или несколько из следующих типов справочной информации:
a) контекстная справка - информация о текущем поле, в котором находится курсор или высвечена программа, включая ее необходимое или целевое (предметное) содержание, ее назначение и потенциальное влияние на работу программного средства;
b) расширенная справка - информация о текущем экране или окне, включая ее назначение и требуемый режим использования;
c) справка о клавишах - информация о применении клавиатуры, функциональном назначении клавиш и их перенаименовании (обозначении);
d) справка о справках - информация об использовании справочной системы в целом;
e) справка о сообщении - информация о том, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;
f) терминологическая справка - определения конкретных элементов, связей с конкретной тематикой и расшифровка обозначений и сокращений;
g) понятийная справка - справочная информация, выдаваемая системой для предупреждения пользователя об ошибках. Может быть структурирована, чтобы первоначально пользователь получал краткое справочное сообщение, а при повторении той же ошибки - более подробное сообщение, и наоборот, пользователь может получить развернутое сообщение при первой ошибке и краткое - при ее повторении.
В спецификации стиля электронной документации могут быть указаны один или несколько из следующих типов диалоговой документации:
a) руководства или рекомендации пользователя - описывают процедуры по применению продукта;
b) командные справки - определяют синтаксис, результаты и целевое назначение каждой команды (только для команд управления системой);
c) рекомендации по сообщению - определяют, что пользователь должен или может сделать в ответ на конкретные системные сообщения, например сообщения об ошибках;
d) административная информация - информация о конфигурации и защите системы, а при необходимости - о ее инсталляции, предназначенная для администратора системы.
Оформление (компоновка) информации в системах справочной и диалоговой (оперативной) документации во многом может определяться возможностями инструментальных средств, используемых при их создании.
Должны быть установлены правила размещения материалов, связанных с электронной документацией, и их местоположение.
Должны быть установлены правила использования в электронной документации подсветок выделяемых элементов и использование цветового оформления.
Использование подсветок и цветов для выделения элементов документации должно быть минимизировано, особенно в случае возможной путаницы между выделенным текстом и гипертекстовыми связями.
Цвета следует использовать осторожно, особенно при отсутствии уверенности в том, что тот же цвет не используется для уведомления о более важной информации. Это особенно важно при наличии у пользователей возможностей выбора различного цветового оформления экранов.
Для четкого выделения элементов и во избежание возникновения при этом проблем по возможности следует основные цвета (красный, зеленый и синий) использовать на фоне белого или черного.
Различные яркие цвета не следует использовать последовательно, так как это может привести к возникновению на экране трехмерных эффектов.
Обычно некоторые цвета имеют определенные смысловые значения (например, красный - «стой» или «опасно», зеленый - «продолжить» или «безопасно») и могут быть выбраны соответственно этому значению. Данный тип цветосочетания следует использовать осторожно, если пользователи могут выбирать различные цветовые оформления экранов.
Колористика экранов дисплеев является сложным вопросом и часто связана с недостаточной проектной проработкой. Документаторам в этом случае следует обращаться за помощью к соответствующим специалистам.
Должны быть установлены правила оформления соответствующих текстов.
Должны быть установлены правила оформления соответствующих заголовков.
Для текста основной части электронной документации должны быть определены следующие элементы:
a) выравнивание (для соответствующих языков);
b) отступы и интервалы.
c) минимальная высота символа.
Для языков романской группы высота символов должна быть не менее 16 и не более 45 угловых минут. Предпочтительной высотой символа являются 20-22 угловые минуты. Угловые минуты используются в качестве показателя высоты символа на видеодисплее; данный показатель отражает охват символа глазом. Он зависит не только от фактической высоты символа на экране, но также от нормального расстояния до экрана. В таблице 1 показано отношение между высотой символа в угловых минутах и миллиметрах на расстоянии в 1 м. Например, на более коротком расстоянии высота пропорционально уменьшается по сравнению с заданной в таблице. В таблице для сравнения также показано соответствующее число отображаемых точек для гарнитуры «Times Roman».
Должны быть установлены правила навигации по электронной документации.
Уровни связей информации в документации должны контролироваться, обеспечивая пользователю возможности возврата в исходный пункт, содержание или указатель без блуждания в документе.
Должны быть выработаны и применены правила структурирования документа. Например, количество связей в каждой информационной цепочке должно быть ограничено числом X. Значение X должно быть таким, чтобы пользователи имели соответствующие возможности для возврата к содержанию или перехода к другим структурным элементам документа. Уровни заголовков также могут быть взаимоувязаны с уровнями сложности документа (например, «В заголовках первого уровня представляется только общая информация»).
Проблемно ориентированная и общая информация должны быть выделены в отдельные разделы с входящими связями между ними, тем самым позволяя пользователю изучить конкретную задачу без непреднамеренного поиска в общих материалах, что может дезориентировать и отвлекать его.
Следует использовать графические материалы. Общая схема, отражающая основные разделы документа с гипертекстовыми связями между ними, дает пользователю ясное визуальное представление о структуре документа.
В начале документа должен быть раздел с рекомендациями пользователю, содержащий информацию по применению диалоговой документации. Данный раздел следует использовать для пояснения структуры документа и правил по его применению.
Должны быть определены правила использования специальных клавиш в диалоговой документации.
Пользователь должен иметь возможность вызова справки, используя конкретную клавишу или комбинацию клавиш, в любой точке программы. Пользователь также должен иметь возможность вызова диалоговой документации с использованием единственной клавиши или комбинации клавиш.
В плане документирования должны быть определены условные наименования и функции всех специальных функциональных клавиш, используемых в системе диалоговой или справочной документации. Применение специальной функциональной клавиши в документации должно быть соотнесено с использованием функциональных клавиш в самом программном приложении.
Лекция №23 Раздел 9 Сертификация программного обеспечения 9.1.Стандарты качества ПО
9.2.Характеристики качества
Основным стандартом качества в области инженерии программного обеспечения в настоящее время является стандарт ISO/IEC 9126. Он определяет номенклатуру, атрибуты и метрики требований качества программного обеспечения. Относительно недавно этот стандарт стал одним из определяющих факторов при моделировании качества программного обеспечения и остаётся им до сих пор.
В дополнение к нему выпущен набор стандартов ISO/IEC 14598, регламентирующий способы оценки этих характеристик. В совокупности они образуют модель качества, известную под названием SQuaRE (Software Quality Requirements and Evaluation).
Общий подход к моделированию качества программного обеспечения заключается в том, чтобы сначала идентифицировать небольшой набор атрибутов качества самого высокого уровня абстракции и затем в направлении "сверху вниз" разбить эти атрибуты на наборы подчиненных атрибутов. Стандарт ISO/IEC 9126 является типичным примером такого подхода.
В рамках модели SQuaRE выделяются следующие шесть основных характеристик качества.
1.Функциональность (точность, согласованность, безопасность, пригодность). Функциональные требования традиционно составляют основной предмет спецификации, моделирования, реализации и аттестации программного обеспечения. Они формулируются в виде утверждений в императивной модальности, описывающих поведение системы. Использование формальных методов позволяет довести уровень отклонения фактического поведения системы от требуемого практически до нуля. Это достигается путем выражения функциональных требований в виде предложений подходящих формальных исчислений, так что верификация сводится к строгому доказательству.
2.Надежность (устойчивость, завершенность, восстанавливаемость). Показатели надежности характеризуют поведение системы при выходе за пределы штатных значений параметров функционирования по причине сбоя в окружении либо в самой системе. При оценке атрибутов надежности применяются методы теории вероятностей и математической статистики. Требования к надежности особенно важны при разработке критических систем обеспечения безопасности жизнедеятельности .Хотя использование формальных методов способствует снижению количества внутренних ошибок (т.е. росту завершенности системы), обеспечение надежности в целом требует специальных подходов, учитывающих специфику различных типов систем.
3.Удобство (эффективность освоения, эргономичность, понимаемость). Соответствие системы требованиям к удобству чрезвычайно трудно поддается оценке. Предлагаемые подходы включают замеры расхода нормативных единиц труда (нормо-часов), затрачиваемого пользователями на овладение системой, а также проведение и анализ экспертных оценок, в том числе с применением методов нечеткой логики (fuzzy logic). В контексте использования формальных методов наилучшим решением представляется изначальная ориентация на формализмы, способные максимально точно отразить структуру исходной предметной области. Например, при создании вычислительных систем критерием адекватности формализма с точки зрения будущего пользователя является поддержка абстрактного математического языка, не зависящего от концептуальных ограничений, накладываемых компьютерными технологиями.
4.Эффективность(по ресурсам и по времени). Атрибуты эффективности традиционно относятся к числу важнейших количественных показателей качества программных систем. Их значения подлежат фиксации в эксплуатационной документации к программным и аппаратным изделиям. Имеется высокоразвитый инструментарий для измерения этих значений. Разработаны также методики, позволяющие прогнозировать интегральные значения показателей эффективности системы исходя из значений этих показателей для компонентов самой системы и ее окружения. Выбору формальных методов обеспечения эффективности следует уделять особое внимание. При этом следует иметь в виду, что, хотя имеется тесная взаимосвязь между производительностью и ресурсоемкостью, подходы к обеспечению каждого из этих требований в общем случае имеют различную природу.
5.Сопровождаемость (простота анализа, изменяемость, стабильность, проверяемость). Требования к сопровождаемости направлены в первую очередь на минимизацию усилий по сопровождению и модернизации системы, затрачиваемых эксплуатационным персоналом. Для их оценки используются различные методики прогнозирования затрат на выполнение типовых процедур сопровождения. Интегральная стоимость сопровождения долгоживущих систем может существенно превышать стоимость их разработки. Сопровождение существенно упрощаются в случае, когда разработка велась с использованием формальных методов, поскольку имеется в определенном смысле исчерпывающий комплект технологической документации и проверочных тестов.
6.Переносимость (адаптируемость, согласованность со стандартами и правилами, гибкость инсталляции, заменяемость). Переносимость системы характеризует степень свободы в выборе компонентов системного окружения, необходимых для ее функционирования. Оценка переносимости затрудняется принципиальной незавершенностью, динамичностью списка возможных вариантов окружения, обусловленной быстрым прогрессом в сфере информационных технологий. Системы, разрабатываемые с использованием формальных методов, как правило, отличаются высоким уровнем переносимости. В частности, если такая система не поддерживает некоторую целевую технологическую платформу, создание "клона" реализации ее абстрактной модели с использованием целевых средств программирования требует существенно меньших затрат, чем замена самой системы либо платформы.
Модель качества, создаваемая в рамках данного стандарта, определяется общими характеристиками продукта. Характеристики же в свою очередь могут быть уточнены, другими словами, иерархично разбиты на подхарактеристики качества. Так, например, характеристика сопровождаемости может быть представлена такими подхарактеристиками как простота анализа, изменяемость, стабильность, проверяемость.
И, наконец, нижний уровень иерархии представляют непосредственно атрибуты программного обеспечения, поддающиеся точному описанию и измерению. Требования качества в свою очередь могут быть представлены как ограничения на модель качества. Оценка качества продукта в таком случае происходит по следующей схеме.
Вначале оцениваются атрибуты программного изделия. Для этого выбирается метрика и градируется шкала оценки в зависимости от возможных степеней соответствия атрибута накладываемым ограничениям. Для каждой отдельной оценки атрибута градация обычно выбирается заново и зависит от требований качества, накладываемых на него. Набор "измеренных" атрибутов представляет собой критерий для оценки подхарактеристики и характеристик, и как результат качества продукта в целом.
Лекция 24.Тема Стандартизация в области программного обеспечения. Стандарты документирования программных средств.
Стандартизация – это деятельность, направленная на разработку и установление требований, норм, правил, характеристик, как обязательных для выполнения, так и рекомендуемых, обеспечивающая право потребителя на приобретение товаров надлежащего качества, а также право на безопасность и комфортность труда.
Цель стандартизации – достижение оптимальной степени упорядочения в той или иной области посредством широкого и многократною использования установленных положений, требований, норм для решения реально существующих, планируемых или потенциальных задач.
Основными результатами деятельности по стандартизации должны быть повышение степени соответствия продукта (услуги), процессов их функциональному назначению, устранение технических барьеров в международном товарообмене, содействие научно-техническому прогрессу и сотрудничеству в различных областях. Стандартизация осуществляется на разных уровнях и также делятся в зависимости от масштаба:
Стандарты имеют большое значение – они обеспечивают возможность разработчикам программного обеспечения использовать данные и программы других разработчиков, осуществлять экспорт/импорт данных. Такие стандарты регламентируют взаимодействие между различными программами. Для этого предназначены стандарты межпрограммного интерфейса, например OLE (Object Linking and Embedding – связывание и встраивание объектов). Без таких стандартов программные продукты были бы “закрытыми” друг для друга.
Все компании-разработчики должны обеспечить приемлемый уровень качества выпускаемого программного обеспечения (ПО). Для этих целей предназначены стандарты качества программного обеспечения или отдельные разделы в стандартах разработки программного обеспечения, посвященные требованиям к качеству программного обеспечения.
В зависимости от возникновения: “де-юре” и “де-факто”. Стандарт “де-факто”– термин, обозначающий продукт какого-либо поставщика, который захватил большую долю рынка и который другие поставщики стремятся эмулировать, копировать или использовать для того, чтобы захватить свою часть рынка. Стандарт “де-юре” создается формально признанной стандартизующей организацией. Он разрабатывается при соблюдении правил консенсуса в процессе открытой дискуссии, в которой каждый имеет шанс принять участие. Ни одна группа не может действовать независимо, создавая стандарты для промышленности. Если какая-либо группа поставщиков создаст стандарт, не учитывающий требования пользователей, она потерпит неудачу.
СТАНДАРТЫ ДОКУМЕНТИРОВАНИЯ ПРОГРАММНЫХ СРЕДСТВ. Создание программной документации – важный этап, так как пользователь начинает свое знакомство с программным продуктом именно с документации. Программная документация должна отвечать на вопросы: для чего предназначен программный продукт, как установить программный продукт, как начать с ним работать. Основу отечественной нормативной базы в области документирования ПС составляет комплекс стандартов Единой системы программной документации (ЕСПД). Сейчас это система межгосударственных стандартов стран СНГ (ГОСТ), действующих на территории Российской Федерации на основе межгосударственного соглашения по стандартизации. Стандарты ЕСПД в основном охватывают ту часть документации, которая создается в процессе разработки ПС, и связаны, по большей части, с документированием функциональных характеристик ПС. В состав ЕСПД входят:
основополагающие и организационно-методические стандарты;
стандарты, определяющие формы и содержание программных документов, применяемых при обработке данных;
стандарты, обеспечивающие автоматизацию разработки программных документов.
В Российской Федерации действует ряд стандартов в части документирования программных средств, разработанных на основе прямого применения международных стандартов ИСО:
ГОСТ Р ИСО/МЭК 9294-93. Информационная технология. Руководство по управлению документированием программного обеспечения. Стандарт полностью соответствует международному стандарту ИСО/МЭК 9294:1990 и устанавливает рекомендации по эффективному управлению документированием ПС для руководителей, отвечающих за их создание. Целью стандарта является оказание помощи в определении стратегии документирования ПС; выборе стандартов по документированию; выборе процедур документирования; определении необходимых ресурсов; составлении планов документирования. ГОСТ Р ИСО/МЭК 9126-93. Информационная технология. Оценка программной продукции. Характеристики качества и руководства по их применению .Стандарт полностью соответствует международному стандарту ИСО/МЭК 9126:1991. В его контексте под характеристикой качества понимается “набор свойств (атрибутов) программной продукции, по которым ее качество описывается и оценивается”. Стандарт определяет шесть комплексных характеристик, которые с минимальным дублированием описывают качество ПС (ПО, программной продукции):
- функциональные возможности;
- надежность;
- практичность;
- эффективность;
- сопровождаемость;
- мобильность.
Эти характеристики образуют основу для дальнейшего уточнения и описания качества ПС. ГОСТ Р ИСО 9127-94. Системы обработки информации. Документация пользователя и информация на упаковке для потребительских программных пакетов. Стандарт полностью соответствует международному стандарту ИСО 9127:1989. В контексте настоящего стандарта под потребительским программным пакетом (ПП) понимается “программная продукция , спроектированная и продаваемая для выполнения определенных функций; программа и соответствующая ей документация, упакованные для продажи как единое целое”. Под документацией пользователя понимается документация, которая обеспечивает конечного пользователя информацией по установке и эксплуатации ПП. Под информацией на упаковке понимают информацию, воспроизводимую на внешней упаковке ПП. Ее целью является предоставление потенциальным покупателям первичных сведений о ПП.
ГОСТ Р ИСО/МЭК 8631-94. Информационная технология. Программные конструктивы и условные обозначения для их представления. Описывает представление процедурных алгоритмов.
ГОСТ Р ИСО/МЭК 12119:1994. Информационная технология. Пакеты программных средств. Требования к качеству и испытания. В этом стандарте установлены требования к качеству пакетов программ и инструкции по их испытаниям на соответствие заданным требованиям. Понятие “пакет программных средств” фактически отождествляется с более общим понятием “программный продукт”, рассматриваемым как совокупность программ, процедур и правил, поставляемых нескольким пользователям для общего применения или функционирования. Каждый пакет программ должен иметь описание продукта и пользовательскую документацию.